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.
http://semver.org not good?
ReplyDeleteWe 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.
DeleteSemver didn't solve any of the listed problems.
Deletesemver major version is for breaking compatibility. This doesn't work for postgres -- I don't think we'd ever allow that.
DeleteI like the current versioning system because it's essentially semver. I've come to rely on it in pgTAP's pg_version() and pg_version_num() functions, as well as PGXN's dependencies. That said, if the change is made, since the new format (which I assume is integer.integer, so 1.14 is greater than 1.2) will effectively still be a semver, just with an implicit .0 appended as necessary, I can adjust my code to compensate. If, on the other hand, the version becomes a numeric (1.2 > 1.14), things get a lot tougher.
ReplyDeleteIt's still integers. So 10.2 < 10.14
DeleteGreat. In that case, the only other preference I would have is that the the next major version wouldn't be 10, but 10.0.
Deletenoooooo!
ReplyDeletePerhaps overkill, but would a legacy_version_numbering guc to make server_version, version() etc report "major.0.minor" help with backwards compatibility?
ReplyDelete> 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.
ReplyDeleteit is a very very weeeeeeeeeeeeeeeaaaaaaaaaak point!
one has to check release notes first! no marketing bullshit, nooooooo!
> The result is arguments about version numbering on the mailing lists every year which waste time and irritate developers.
ReplyDeletejust another weeeeeeeeeeeeeeeaaaaaaaaaak argument!
"waste time" happens because there is room to lift up motivation amd goals!
This comment has been removed by the author.
ReplyDeleteI'm OK with any scheme that meets the following conditions:
ReplyDelete1) It's easy to compare version numbers, to see which is newer. This includes comparing new versions with the existing version numbers.
2) There's one number that changes IF AND ONLY IF a dump/restore or pg_upgrade is required.
Can't you like, go up to 9.9 and then to 10 ?
ReplyDeleteIf a crazy feature comes (say auto-sharding or something) you can make another devel-meeting to discuss if it needs to raise it again.
Automation engineer and administrator/support for thousands of server for hundreds of clients doing and supporting automated full stack cloud deployments. This is going to be a major PITA and will just create more work for the community at large with no tangible benefits to us. At the very least we're going to have to update our client documentation for our platform and have endless conversations with confused clients explaining the change. What's more, I agree that this is weak:
ReplyDelete> 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.
The first part, especially. For the second part, we've already done that and have it documented (both Postgres and my company). Explaining that it used to work one way and now (then) works another (for a minimum of five years, right?) because the hackers couldn't skip the bickering and hold a simple vote will not look good. Sure, if we could just magically get everyone onto the latest version it wouldn't be an issue but that transition will make explaining Postgres's versioning to regular users more difficult, not less.
Thank you! You're the kind of user we want to hear from. Can you give some examples of what this will break for you?
DeleteWell, apparently check_postgres will break, per Greg's comment, and we do use that extensively. We can handle/manage how new versions of everything gets released, including our own code (which I actually think should be okay as it looks like in most places in our code we're just using a simple regex max of /([0-9]+\.?)+/ which we then match against package names/versions). The main issue is having to manage stuff like coordinating other package updates so that they don't break, potentially miss things, rewrite customer facing documentation, etc. all for no actual improvement or change in fuctionality.
DeleteIf the yearly argument around the epoch number is such a pain why not just implement some kind of simple vote? Like 1 week of comments the week before the first alpha is rolled or before PGCon followed by a vote from committers. Ties could be decided by something fun at the conference.
- Erik Jones
Oh, one big thing that we're going to have to change big-time is our directory install pattern. Right now it's /db/postgresql//data and we have a lot of stuff that matches against a /\d\.\d/ type of pattern there. What's more, there's really no way for me to say how many of our clients will have their code break for similar reasons there.
Deletecheck_postgres will break. Sure, it will be relatively easy to fix, but will the new release of check_postgres get packaged and installed on everyone's machine before PG 10 is released? No. And forcing people to update their check_postgres for a reason like this is weak. Just keep X.Y.Z and only update X. Problem solved, with literally no impact on anyone else.
ReplyDeleteThanks, Greg.
Deletecheck_postgres doesn't use the sortable version number?
No, it's not libpq based.
DeleteFWIW, DBD::Pg should be fine, as it uses PQserverVersion. Indeed, it is the program that drove me to write PQserverVersion in the first place! In theory, a DBD::Pg compiled against Postgres 7x and querying the new Postgres 10 will have problems, but that's a use case I am not going to spend any cycles worrying about. :)
DeleteThis comment has been removed by the author.
ReplyDeleteThe problem is that nobody has been able to come up with a clear rule in the last 6 years.
Delete