Re: 10.0

Hi,

I recently bumped into http://semver.org/

It can be interesting to participants of this discussion.

Especially motivation for minor version (middle number).

Best,

Grazvydas

On Mon, Jun 20, 2016 at 9:30 PM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger <hornschnorter(at)gmail(dot)com>
> wrote:
>
>>
>> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <jd(at)commandprompt(dot)com>
>> wrote:
>> >
>> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
>> >
>> >>> Now maybe you have some other idea in mind, but I don't quite
>> >>> understand what it is.
>> >>
>> >> I do, indeed, and here it is:
>> >>
>> >> When considering whether to *back port* a change, we typically do so
>> >> on the basis that bug fixes are back ported, features are not. In my
>> >> proposed versioning scheme, you could back port any feature that is
>> >> compatible with the old version, and bump the middle number to alert
>> >> users that you've not just back ported a bug fix, but a feature. Any
>> new
>> >> features that are not compatible don't get back ported.
>> >>
>> >> If you fix a bug on master during development, you can back port that
>> >> as well. But instead of bumping the middle number, you bump the last
>> >> number.
>> >>
>> >> Somebody running a version that is three major versions back could
>> >> still get the advantage of new features, so long as those new features
>> >> are not incompatible. It's frequently not nearly so easy to run
>> pg_upgrade
>> >> as it is to run rpm -U. You get downtime either way, but the elapsed
>> >> time of that downtime is orders of magnitude different.
>> >>
>> >> Someone else running that same version from three major versions ago
>> >> can take a more conservative policy, and only upgrade bug fixes, and
>> >> forego the back ported features.
>> >>
>> >> You still have one major version release per year. At that time, you
>> can
>> >> also release back-port versions of prior major versions.
>> >
>> > OFFLIST:
>> >
>> > You are fighting a losing if noble battle.
>>
>> I think all my emails on this subject have been seriously misunderstood.
>> Perhaps the problem is that I don't understand some critical issue. Can
>> you please help me understand this part:
>>
>> It seems like people want releases, starting with 10.0, to be named things
>> like 10.0, 10.1, 10.2,..., but for the purposes of communicating with
>> programs
>> like nagios refer to them as 10.0.0, 10.0.1, 10.0.2
>>
>> Is that right?
>>
>> That's the part that really annoys me, and I keep trying to argue for not
>> doing
>> that, and people keep replying to other parts of my messages rather than
>> replying to the core part of what I am saying.
>>
>> Why would any sensible person want a release to sometimes be called
>> "10.4", but the exact same release sometimes referred to as "10.0.4"?
>> This is just going to confuse average software users, as they would never
>> expect that 10.4 and 10.0.4 are the same thing.
>>
>> Have I misunderstood what is being proposed?
>>
>
> ​The software is only ever going to report 10.0.4 OR 10.4. The area of
> concern is that people are going to get annoyed at saying: "that was fixed
> in 10.0.4​" and so mailing lists and other forums where people write the
> numbers instead of a computer are going to be littered with: "that was
> fixed in 10.4".
>
> So now human speak and machine speak are disjointed.
>
> ​The machine form output for that release is going to be 100004 regardless
> of the decision to make the human form 10.4 or 10.0.4
>
> Do you have a problem with the human form and machine forms of the version
> number being different in this respect? I don't - for me the decision of a
> choice for the human form is not influenced by the fact the machine form
> has 6 digits (with leading zeros which the human form elides...).
>
> This thread started with complaint that people are parsing our human form
> output instead of the machine form. The OP later admitted that he didn't
> realize that a machine form was so readily available. That is worry-some,
> since I doubt that is an isolated incident,​ and leads to the discussion of
> what form the human intended version should take.
>
> David J.
>
>