Re: 9.6 -> 10.0

So, I have a simplified proposal, inspired by David G's comments.

Get rid of the middle number entirely.  Increment the first number for every
major version, use the second number to indicate patches.

So then the major releases from now on would be 10.0, 11.0, 12.0 etc.

Then this whole thread is bike shedding we can avoid.  No need to justify 9.x vs
10 etc which is heavily arbitrary.

EVERY major release is quite significant, so just give them all a new high
number, the end?

Would this satisfy everyone?

As such, assuming this proposal is adopted, I firmly support 10.0 for the next
major.

Whereas, if this proposal is not adopted, I see no strong reason to pick a
winner between 9.6 and 10.0.

-- Darren Duncan

On 2016-05-09 5:44 PM, David G. Johnston wrote:
> On Mon, May 9, 2016 at 5:19 PM, Darren Duncan <darren@darrenduncan.net>wrote:
>
>     On 2016-05-09 3:24 PM, Josh berkus wrote:
>
>         On 05/09/2016 03:18 PM, Darren Duncan wrote:
>
>             Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
>             optionally more.  MAJOR must be increased when a backwards-compatibility
>             break is made of any kind (such as removing a feature), otherwise MINOR
>             must be increased for any forwards-compatibility break (such as adding a
>             feature), otherwise PATCH must be increased for changes that shouldn't
>             break any kind of compatibility, except for fixing bugs or security
>             holes where the old behavior was not being relied on for any working
>             uses.  MATURITY means eg alpha/beta/rc/production etc.
>
>         That seems like that would be an argument against 10.0?  Since we didn't
>         break backwards compat?
>
>     To be clear, I am talking about backwards compatibility in a holistic sense,
>     both API *and* database cluster file format.
>
>     0.  Start with the context of a standalone (not replicated) Postgres 9.5
>     database cluster D1 and Postgres 9.5 binaries P1 and an application A1 using
>     those.  A1 also includes the set of SQL/etc queries made manually by users.
>
>     1.  Shutdown the Postgres servers P1, install new Postgres 9.6 binaries P2,
>     start Postgres servers P2, this all without making any changes to D1 or A1
>     which includes not running pg_upgrade etc.
>
>     2.  Use A1 for awhile without making any changes to it.
>
>     3.  Shutdown the Postgres 9.6 servers P2, reinstall or use the previous
>     Postgres 9.5 binaries P1, start Postgres servers P1.
>
>     If despite switching to 9.6 and then back to 9.5 without making any changes
>     to the application, everything just keeps working, then 9.6 is
>     backwards-compatible with 9.5 in the holistic sense.
>
>     When using 9.6 in the same way as 9.5 was used breaks the ability to use a
>     database cluster as is with 9.5, backwards compatibility is broken.
>
> ​Default maturity is "production" - we introduce beta, etc... at the end of a
> release cycle.
>
> I'm highly doubtful we could go an entire year without introducing a backward
> incompatibility - and to date we've never attempted to avoid doing so.  Thus
> what this proposal boils down to is:
>
> Major.Patch[.Maturity]
>
> Minor would never be incremented and would constitute harmful noise (it would
> imply potential that doesn't practically exist) if specified explicitly

I agree with you.  Having the separate MINOR is more of a project-agnostic mold
and for Postgres doesn't really help when the rules would make incrementing
MAJOR what is done for nearly every break.  Having MINOR works much better for
say SQLite who haven't had a backwards-compatibility break in over 13 years.

> IOW - We should just go to 10.0 in lieu of a 9.7 release, all then bug-fix
> releases increment 10.1, 10.2, 10.3, etc..., and two years from now we release 11.0

I agree/believe that if Postgres went with a semantic versioning scheme, it
should start off with a MAJOR increase to more clearly mark when the regime
change happened, as you say.

Or even if we essentially kept things as they are now, getting rid of the middle
number is helpful.  Just increment the first number for every major release and
the second number for bug fixes.  Then we can avoid all the bikeshedding of this
thread.

> Semantic versioning has become more prevalent as more and more project have
> either weekly/monthly cycles OR indefinite cycles where the increment will
> depend on what just got patched at any given point in time.  PostgreSQL doesn't
> fit into either of those molds so 4+ semantic levels just doesn't make sense.

I agree.

> ​I'm sticking to my opinion that because of our present numbering scheme and our
> 5-year support cycle we should increment major accordingly to those project
> policies and should consider aligning advocacy on that time pulse so certain
> aspects are emphasized during years 0,1,2,3,4 of the release cycle.  But, then
> again, I'm not close enough to this to say that what we have now is even broken
> and warrants changing.  All I have is an unproven setup based upon logic and
> symmetry with only minimal practical experience in advocacy.​

-- Darren Duncan