Re: 9.6 -> 10.0 - Mailing list pgsql-advocacy
| From | David G. Johnston |
|---|---|
| Subject | Re: 9.6 -> 10.0 |
| Date | |
| Msg-id | CAKFQuwbFhQkwekRUbS9kpYarFzRk1k7jQ6eDWaVgx83Xkx7SRQ@mail.gmail.com Whole thread Raw |
| In response to | Re: 9.6 -> 10.0 (Darren Duncan <darren@darrenduncan.net>) |
| Responses |
Re: 9.6 -> 10.0
|
| List | pgsql-advocacy |
On 2016-05-09 3:24 PM, Josh berkus wrote:On 05/09/2016 03:18 PM, Darren Duncan wrote:Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
optionally more. MAJOR must be increased when a backwards-compatibility
break is made of any kind (such as removing a feature), otherwise MINOR
must be increased for any forwards-compatibility break (such as adding a
feature), otherwise PATCH must be increased for changes that shouldn't
break any kind of compatibility, except for fixing bugs or security
holes where the old behavior was not being relied on for any working
uses. MATURITY means eg alpha/beta/rc/production etc.
That seems like that would be an argument against 10.0? Since we didn't
break backwards compat?
To be clear, I am talking about backwards compatibility in a holistic sense, both API *and* database cluster file format.
0. Start with the context of a standalone (not replicated) Postgres 9.5 database cluster D1 and Postgres 9.5 binaries P1 and an application A1 using those. A1 also includes the set of SQL/etc queries made manually by users.
1. Shutdown the Postgres servers P1, install new Postgres 9.6 binaries P2, start Postgres servers P2, this all without making any changes to D1 or A1 which includes not running pg_upgrade etc.
2. Use A1 for awhile without making any changes to it.
3. Shutdown the Postgres 9.6 servers P2, reinstall or use the previous Postgres 9.5 binaries P1, start Postgres servers P1.
If despite switching to 9.6 and then back to 9.5 without making any changes to the application, everything just keeps working, then 9.6 is backwards-compatible with 9.5 in the holistic sense.
When using 9.6 in the same way as 9.5 was used breaks the ability to use a database cluster as is with 9.5, backwards compatibility is broken.
Default maturity is "production" - we introduce beta, etc... at the end of a release cycle.
I'm highly doubtful we could go an entire year without introducing a backward incompatibility - and to date we've never attempted to avoid doing so. Thus what this proposal boils down to is:
Major.Patch[.Maturity]
Minor would never be incremented and would constitute harmful noise (it would imply potential that doesn't practically exist) if specified explicitly
IOW - We should just go to 10.0 in lieu of a 9.7 release, all then bug-fix releases increment 10.1, 10.2, 10.3, etc..., and two years from now we release 11.0
Semantic versioning has become more prevalent as more and more project have either weekly/monthly cycles OR indefinite cycles where the increment will depend on what just got patched at any given point in time. PostgreSQL doesn't fit into either of those molds so 4+ semantic levels just doesn't make sense.
I'm sticking to my opinion that because of our present numbering scheme and our 5-year support cycle we should increment major accordingly to those project policies and should consider aligning advocacy on that time pulse so certain aspects are emphasized during years 0,1,2,3,4 of the release cycle. But, then again, I'm not close enough to this to say that what we have now is even broken and warrants changing. All I have is an unproven setup based upon logic and symmetry with only minimal practical experience in advocacy.
David J.
pgsql-advocacy by date: