> On Jun 18, 2016, at 5:48 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
