Re: 10.0

> On Jun 20, 2016, at 11:30 AM, 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...).

I don't have a problem with it if humans always use a two part number. I don't read
the number 100004 as being three parts, nor as being two parts, so it doesn't matter.
What got me to respond this morning was Josh's comment:

"Realistically, though, we're more likely to end up with 10.0.1 than 10.1."

He didn't say "100001 than 10.1", he said "10.0.1 than 10.1", which showed that we
already have a confusion waiting to happen.

Now, you can try to avoid the confusion by saying that we'll always use all three
digits of the number rather than just two, or always use two digits rather than three.
But how do you enforce that? If in some sense the middle number exists, but is
always zero, then some people will mention it and some won't, with the result that
10.0.x and 10.x will be used by different people at different times to refer to the same
release.

The problem that Tom and others mentioned upthread (rather a while ago) is that
up until now, we've had three digits in the version numbers, but the first two numbers
really just mean one thing, "major", and the last number means "minor". IIUC, he
wanted to stop using two separate digits where clearly just one would suffice. Hence
the proposal to go to things like 10.0, 10.1. But others chimed in saying that we need
to keep it three parts for compatibility reasons, so how about we just have the middle
number always be zero. My response to that is what I've just said. You can't do that
without creating ambiguity in future version numbers, because of how people use
language. If you want to avoid the ambiguity and confusion going forward, all the
numbers in the scheme must have meaning and not be mere placeholders. I gave a
suggestion about what the middle number *could* mean, which I don't deny is what
I'd like best, but it's just a suggestion to avoid the confusion inherent in people eliding
the middle number sometimes but not other times.