Drake versioned releases do not self-identify

[stonier]

Or at least, I haven't found anything in a grep of a versioned release (e.g. drake-0.25.0-bionic.tar.gz. The drake VERSION.txt file provides only the date / commit hash.

What would be useful:

• Drake's VERSION.txt can communicate version possibly with the ability to distinguish between snapshot (nightly) and release binaries.
• C++ version macros in headers
• Python version numbers from modules a'la PEP-0396
• A drake_VERSION in drake-config.cmake and drake-config-version.cmake.
  • Now filed as Add version numbers in drake-config.cmake #21325.
• Bazel versioning in the release, similarly
• drake.__version__ in pydrake.

The first one at least would be a good starting point - that will allow humans and scripts to introspect what's installed more efficiently than having to associate with releases on the server.

[jamiesnape]

Yes, this is an issue for me too. The version number is effectively decided after the event (the release notes are missing from the commit that forms the release). It will need fixing up by tooling or manually, though changing the VERSION.txt changes the SHA, so really we need to fix this before the packages go to GitHub, rather than before they go to S3.

I have to fix this for apt packaging too.

[jamiesnape]

Probably having Jenkins have a job that takes a SHA parameter and a release number would be a start. We are also missing drake-config-version.cmake for CMake.

[jamiesnape]

Also Bazel has the ability to embed release information, which we do not use at present.

[jamiesnape]

(To me this is high priority, that is, not necessarily that it should be labeled high priority, but it would make my life disproportionately easier if we achieved this, especially if the release notes were in the release.)

[stonier]

We are also missing drake-config-version.cmake for CMake.

Just went looking for that this morning (needed it). Added it to the list in the issue description.

With regards to priorities, +1 from me. Justifying it's priority really ought to be derived from the priority allocated to user support - this one is a fundamental release mechanism for users. It's rarely used internally by developers (@jamiesnape I imagine you're the exception), so justifying it's priority from that angle will always be difficult.

[jamiesnape]

(@jamiesnape I imagine you're the exception),

I am always an exception

But seriously, I need version numbers and release notes (or just release notes that have a clear regex for version number) so that they make to the users in the multiple places they need embedding and I am a proto-user who is supposed to show people how to use the version numbers in the examples. I actually need the tagged commit to contain at least the code to generate the correctly versioned files.

[jamiesnape]

C++ version macros in headers

This could be achieved via some Bazel and C++ code and the flag --embed_label IIRC.

[jwnimmer-tri]

The list of places to note a version badge in the top post is sound, and a great idea.

On the topic of priority, this is one of the most important issues in its subject area, but we just have a lot of projects already in flight (apt packages, catching up on macOS support, website refresh) that we need to carry over the finish line before revisiting the versioned-release machinery.