Wednesday, May 18, 2016

Changing PostgreSQL Version Numbering

Per yesterday's developer meeting, the PostgreSQL Project is contemplating a change to how we do version numbers.  First, let me explain how we do version numbers now.  Our current version number composition is:

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:


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.




24 comments:

  1. Replies
    1. 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.

      Delete
    2. Semver didn't solve any of the listed problems.

      Delete
    3. semver major version is for breaking compatibility. This doesn't work for postgres -- I don't think we'd ever allow that.

      Delete
  2. I 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.

    ReplyDelete
    Replies
    1. It's still integers. So 10.2 < 10.14

      Delete
    2. Great. In that case, the only other preference I would have is that the the next major version wouldn't be 10, but 10.0.

      Delete
  3. Perhaps overkill, but would a legacy_version_numbering guc to make server_version, version() etc report "major.0.minor" help with backwards compatibility?

    ReplyDelete
  4. > 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.

    it is a very very weeeeeeeeeeeeeeeaaaaaaaaaak point!

    one has to check release notes first! no marketing bullshit, nooooooo!

    ReplyDelete
  5. > The result is arguments about version numbering on the mailing lists every year which waste time and irritate developers.

    just another weeeeeeeeeeeeeeeaaaaaaaaaak argument!
    "waste time" happens because there is room to lift up motivation amd goals!

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. I'm OK with any scheme that meets the following conditions:

    1) 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.

    ReplyDelete
  8. Can't you like, go up to 9.9 and then to 10 ?
    If a crazy feature comes (say auto-sharding or something) you can make another devel-meeting to discuss if it needs to raise it again.

    ReplyDelete
  9. 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:

    > 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.

    ReplyDelete
    Replies
    1. 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?

      Delete
    2. Well, 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.

      If 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

      Delete
    3. 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.

      Delete
  10. check_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.

    ReplyDelete
    Replies
    1. Thanks, Greg.

      check_postgres doesn't use the sortable version number?

      Delete
    2. FWIW, 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. :)

      Delete
  11. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. The problem is that nobody has been able to come up with a clear rule in the last 6 years.

      Delete