Re: 10.0 - Mailing list pgsql-hackers

On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <jd@commandprompt.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.