Re: 10.0

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)pgadmin(dot)org>, Thom Brown <thom(at)linux(dot)com>, David Fetter <david(at)fetter(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: 10.0
Date: 2016-06-30 05:05:53
Message-ID: a4bfdc6c-0f65-6d45-cd45-42a4fed38867@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21/06/16 03:53, Mark Dilger wrote:
>> On Jun 18, 2016, at 5:48 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>
>> On 06/16/2016 11:01 PM, Craig Ringer wrote:
>>> I thought about raising this, but I think in the end it's replacing one
>>> confusing and weird versioning scheme for another confusing and weird
>>> versioning scheme.
>>>
>>> It does have the advantage that that compare a two-part major like
>>> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
>>> since it'll be 100001 and 100002. So it's more backward-compatible. But
>>> ugly.
>>>
>> Realistically, though, we're more likely to end up with 10.0.1 than
>> 10.1. I don't think we're anywhere near plumbing the depths of the
>> stuff which will break because folks are parsing our version numbers
>> with regexes. In more major software, this will break nagios
>> check_postgres.
> Having a 3 part versioning scheme where the middle portion is always
> zero makes the least sense to me of any of the proposals. If we're going
> to have the pain and hurting of moving to a 2 part versioning scheme,
> and breaking nagios and what not, then lets just get on with it. If we're
> going to keep all three parts, can we please use my proposal earlier in
> this thread where A.B.C are allocated for:
>
> C++: bug fixes only
> B++: new features added, but still backward compatible with prior version
> A++: new features added, not backward compatible, pg_upgrade required
>
> If every new feature release ends up requiring pg_upgrade, then B will
> always be zero, which is no worse than your proposal. But at least users can
> refer to part B to learn something useful, namely whether they will need to
> run pg_upgrade as part of upgrading their existing cluster.
>
> This has the advantage that new minor features, like adding a new guc, can
> be released sooner than the next major release, but does not have to be
> released in disguise as if it were a bug fix.
>
> This is not a plea for keeping the three part versioning system. It's just
> a plea not to have a 2 part versioning system masquerading as a three
> part versioning system, or vice versa.
>
> mark
>
>
I agree with this!

I hate the rampant inflation associated with numbering schemes like
FireFox - the numbers of no meaning at all, other than something
non-trivial has been changed, with no indication at all about how
non-trivial!

Cheers,
Gavin

In response to

  • Re: 10.0 at 2016-06-20 15:53:55 from Mark Dilger

Responses

  • Re: 10.0 at 2016-06-30 12:15:41 from Alvaro Herrera

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-06-30 06:12:50 Re: Reviewing freeze map code
Previous Message Michael Paquier 2016-06-30 04:27:21 Re: WIP: About CMake v2