Re: 10.0 - Mailing list pgsql-hackers
From | Gavin Flower |
---|---|
Subject | Re: 10.0 |
Date | |
Msg-id | a4bfdc6c-0f65-6d45-cd45-42a4fed38867@archidevsys.co.nz Whole thread Raw |
In response to | Re: 10.0 (Mark Dilger <hornschnorter@gmail.com>) |
Responses |
Re: 10.0
|
List | pgsql-hackers |
On 21/06/16 03:53, Mark Dilger wrote: >> On Jun 18, 2016, at 5:48 PM, Josh Berkus <josh@agliodbs.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
pgsql-hackers by date: