Re: 10.0

On Monday, June 20, 2016, Mark Dilger <hornschnorter@gmail.com> wrote:

>
> > On Jun 18, 2016, at 5:48 PM, Josh Berkus <josh@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.