Re: 10.0
От | Merlin Moncure |
---|---|
Тема | Re: 10.0 |
Дата | |
Msg-id | CAHyXU0yv4SqBYievohM+VkFZPwZGPhXy_VKbP417UmY37SMAkQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 10.0 (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: 10.0
|
Список | pgsql-hackers |
On Fri, Jun 17, 2016 at 1:01 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 17 June 2016 at 08:34, Greg Stark <stark@mit.edu> wrote: >> >> So we would release 10.0.0 and 10.0.1 and the next major release would be >> 11.0.0. >> >> This would have two benefits: >> >> 1) It emphasises that minor releases continue to be safe minor updates >> that offer the same stability guarantees. Users would be less likely to be >> intimidated by 10.0.1 than they would be 10.1. And it gives users a >> consistent story they can apply to any version whether 9.x or 10.0+ > > > And matches semver. > >> >> 2) If we ever do release incompatible feature releases on older branches >> -- or more likely some fork does -- it gives them a natural way to number >> their release. > > Seems unlikely, though. > > 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. Ugliness is a highly subjective qualifier. OTOH, Backwards compatibility, at least when the checks are properly written :-), is a very objective benefit. merlin
В списке pgsql-hackers по дате отправления: