On Monday, June 20, 2016, Mark Dilger <hornschnor...@gmail.com> wrote:
> > > On Jun 18, 2016, at 5:48 PM, Josh Berkus <j...@agliodbs.com > <javascript:;>> 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. > > In practical effect that is exactly what your proposal does. You just feel better because you defined when B is allowed to change even though it never should happen based upon our project policy. And any rare exception can justifiably be called a bug fix because, face it, it would only happen if someone reports a bug. If we keep the middle digit it will be for compatibility reasons. Let's not cause people to infer something that isn't true by saying it could change. David J.
