Re: 10.0

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: 10.0
Дата
Msg-id 8CA35A7F-E473-4BED-B2D9-C98953B609B3@gmail.com
обсуждение исходный текст
Ответ на Re: 10.0  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: 10.0  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: 10.0  (Mark Dilger <hornschnorter@gmail.com>)
Re: 10.0  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Список pgsql-hackers
> 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: 10.0