Re: 10.0
От | Jeff Janes |
---|---|
Тема | Re: 10.0 |
Дата | |
Msg-id | CAMkU=1xaBHSudV3JsSUzjJMg3EuYiAjCi5u=qmqiFJZ+TfBNKA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 10.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, May 14, 2016 at 8:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.janes@gmail.com> writes: >> There are lots of improvement which get done to in-memory data >> structures that wouldn't require a pg_dump/pg_upgrade, which could in >> principle be ported into prior major versions if we had the resources >> (reviewing, testing, packaging) to do it, with an increase in the >> middle number. Maybe we will never find the resources to do that, but >> why should that assumption get baked into the numbering scheme? > > If we were to do that today, it'd just be an increase in the minor number. > I don't see why we'd need to change that approach. We've rejected back-patching such improvements in the past on the grounds that it was at least theoretically possible that it would negatively affect someone, even if it were a win overall for most people, and users shouldn't be forced to adopt that risk in order to get security or corruption bug fixes that go into the minor number increments. > The real blocking > factors there are about manpower and stability of the resulting code, not > about whether you need some special version numbering to describe it. If we did overcome the man-power and stability problems, we would certain run into the version numbering one pretty quickly, under both the existing versioning system and the two-part system. And I don't think that using something at least vaguely like SemVer is really "special", if anything it is less special than either the existing or the dominant proposal. Cheers, Jeff
В списке pgsql-hackers по дате отправления: