9 . 5 . 3
Major1 . Major2 . Minor
That is, the second number is the "major version" number, reflecting our annual release. The third number is the update release number, reflecting cumulative patch releases. Therefore "9.5.3" is the third update to to version 9.5.
The problem is the first number, in that we have no clear criteria when to advance it. Historically, we've advanced it because of major milestones in feature development: crash-proofing for 7.0, Windows port for 8.0, and in-core replication for 9.0. However, as PostgreSQL's feature set matures, it has become less and less clear on what milestones would be considered "first digit" releases. The result is arguments about version numbering on the mailing lists every year which waste time and irritate developers.
As a result, the PostgreSQL Project is proposing a version numbering change, to the following:
10 . 2
Major . Minor
Thus "10.2" would be the second update release for major version 10. The version we release in 2017 would be "10" (instead of 10.0), and the version we release in 2018 will be "11".
The "sortable" version number available from the server, libpq, and elsewhere would remain the same six digits, zero-filled in the middle. So 10.2 would be 100002.
The idea is that this will both put an end to the annual arguments, as well as ending the need to explain to users that 9.5 to 9.6 is really a major version upgrade requiring downtime.
Obviously, there is potential for breakage of a lot of tools, scripts, automation, packaging and more in this. That's one reason we're discussing this now, almost a year before 10 beta is due to come out.
The reason for this blog post is that I'm looking for feedback on what this version number change will break for you. Particularly, I want to hear from driver authors, automation engineers, cloud owners, application stack owners, and other folks who are "downstream" of PostgreSQL. Please let us know what technical problems this will cause for you, and how difficult it will be to resolve them in the next nine months.
We are not, at this point, interested in comments on how you feel about the version change or alternate version naming schemes. That discussion has already happened, at length. You can read it here, here, and here, as well as at the developer meeting.
Places to provide feedback:
- comments on this blog
- posts on the pgsql-hackers or pgsql-advocacy mailing lists
- PostgreSQL Facebook group
Thanks for any feedback you can provide.
Note that the next release of PostgreSQL, due later this year, will be "9.6" regardless. We're deciding what we do after that.
