Re: 10.0

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: 10.0
Дата
Msg-id C4FF7165-ABBF-4980-9F54-176C1844AFAA@gmail.com
обсуждение исходный текст
Ответ на Re: 10.0  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: 10.0  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>
> On 06/20/2016 10:45 AM, Mark Dilger wrote:
>
>>> Now maybe you have some other idea in mind, but I don't quite
>>> understand what it is.
>>
>> I do, indeed, and here it is:
>>
>> When considering whether to *back port* a change, we typically do so
>> on the basis that bug fixes are back ported, features are not.  In my
>> proposed versioning scheme, you could back port any feature that is
>> compatible with the old version, and bump the middle number to alert
>> users that you've not just back ported a bug fix, but a feature.  Any new
>> features that are not compatible don't get back ported.
>>
>> If you fix a bug on master during development, you can back port that
>> as well.  But instead of bumping the middle number, you bump the last
>> number.
>>
>> Somebody running a version that is three major versions back could
>> still get the advantage of new features, so long as those new features
>> are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
>> as it is to run rpm -U.  You get downtime either way, but the elapsed
>> time of that downtime is orders of magnitude different.
>>
>> Someone else running that same version from three major versions ago
>> can take a more conservative policy, and only upgrade bug fixes, and
>> forego the back ported features.
>>
>> You still have one major version release per year.  At that time, you can
>> also release back-port versions of prior major versions.
>
> OFFLIST:
>
> You are fighting a losing if noble battle.

I think all my emails on this subject have been seriously misunderstood.
Perhaps the problem is that I don't understand some critical issue.  Can
you please help me understand this part:

It seems like people want releases, starting with 10.0, to be named things
like 10.0, 10.1, 10.2,..., but for the purposes of communicating with programs
like nagios refer to them as 10.0.0, 10.0.1, 10.0.2

Is that right?

That's the part that really annoys me, and I keep trying to argue for not doing
that, and people keep replying to other parts of my messages rather than
replying to the core part of what I am saying.

Why would any sensible person want a release to sometimes be called
"10.4", but the exact same release sometimes referred to as "10.0.4"?
This is just going to confuse average software users, as they would never
expect that 10.4 and 10.0.4 are the same thing.

Have I misunderstood what is being proposed?

The only reason I talk about using the middle number for this other purpose
is to forestall people assuming that they can elide the middle number of a
three number system, such that it gets elided sometimes but not other times.
I was quite clear in my email this morning that I'm not arguing for a three
number system.  I'm perfectly ok with a two number system.  I just don't want
a "let's confuse everybody by making each and every release have two
different names" system.

mark


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: 10.0
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: 10.0