Re: New versioning scheme

Magnus Hagander wrote:
> On Thu, May 12, 2016 at 7:00 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:

> > I think we should keep the minor major but be more generous in upping
> > the major major. I don't think we need to have a hard policy about it,
> > but about upping it two or three times a decade should be in the right
> > ballpark.
>
> Is everybody using the same term her?
>
> Per our website, which is our public face, "major version" means 9.4, 9.5
> etc. Minor versions are 9.5.2, 9.5.3. the "9.x" has no name.
>
> Are people really talking about getting rid of major/minor versions, or
> just changing the format of the major version number?
>
> Let's make sure we all use the same terms...

Sorry. I used "major major" to refer to the 9 and "minor major" to
refer to the 5 in "9.5". Combining both, "9.5" would be the "major".

Greg is suggesting to keep everything intact but to never again
increment the "minor major", i.e. all versions be X.0 (10.0, 11.0, 12.0
would be the 2016, 2017, 2018 releases, roughly). I disagree with this
idea, because the .0 becames useless noise.

Others have suggested to remove the "minor major" altogether and just
keep the major major, i.e. 10 would be the 2016 release, 11 would be the
2017 release, 12 would be the 2018 release. I don't like this very much
because it's disruptive and confusing: each bugfix release would become
11.1 12.2 etc which would be confused with a regular major release by
people used to our current versioning scheme.

My suggestion is to keep everything as today, but increase the
"major major" more frequently, and to continue to use the "minor major"
as today, i.e. increase yearly and reset to 0 when the major major is
increased.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services