Re: 10.0

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 10.0
Date: 2016-06-20 18:30:26
Message-ID: CAKFQuwZZAeBJR5F-5XQ1=t+gfQ2fHz5qLsTRarAzbbRUtnZiMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

  • Re: 10.0 at 2016-06-20 18:14:44 from Mark Dilger

Responses

  • Re: 10.0 at 2016-06-20 19:07:34 from Gražvydas Valeika
  • Re: 10.0 at 2016-06-20 19:08:08 from Mark Dilger

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2016-06-20 18:34:35 Re: primary_conninfo missing from pg_stat_wal_receiver
Previous Message David G. Johnston 2016-06-20 18:22:42 Re: 10.0