Revisiting tradition: branches and tags

[Dr. Matthias St. Pierre]

I love the new naming scheme, in particular the fact that it's all-lowercase and does not
mix dashes and underscores anymore. I don't recall how often I cursed about the current
scheme which is so typer unfriendly.

I'd like to see *all* stable branch names and release tags converted to new-style uniformly
(keeping the old names for compatibility), so we have an overall consistent scheme and people
don't need to switch back and forth between naming conventions in the future when doing
historical investigations. The old names could be deprecated for later removal.

Matthias



> -----Original Message-----
> From: openssl-project <openssl-project-bounces at openssl.org> On Behalf Of Richard Levitte
> Sent: Friday, April 10, 2020 8:28 PM
> To: openssl-project at openssl.org
> Subject: Revisiting tradition: branches and tags
> 
> Once upon a time, there was CVS (*).
> 
> The story could stop there, but since CVS was what was available,
> OpenSSL was versioned with CVS.
> 
> Among limitations that came with CVS was the allowed syntax in tag and
> branch names; letters, digits, dashes and underscores.  At the time,
> eveyone that wanted to encode a version number in a tag had to convert
> periods to some other character.  We chose underscores, ending up with
> tags like this:
> 
>     OpenSSL_0_9_7-beta2
>     OpenSSL_0_9_7a
> 
> Furthermore, the culture that we have with git, where branches are
> being pulled between repositories...  where you can actually have a
> multitude of repositories and pull data between them, was very hard if
> not practically impossible with CVS.  So, we occasionally had feature
> branches for longer term work.  To distinguish our so called stable
> branches, we had branch names with '-stable' added at the end:
> 
>     OpenSSL_0_9_7-stable
> 
> We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but
> I guess that was too easy to mix up with our letter releases.
> 
> With git, however, there's no technical reason why we must maintain
> what was originally a technical limitation.  I therefore propose that
> we start using tags like this starting with OpenSSL 3.0:
> 
>     openssl-3.0.0-alpha1
>     openssl-3.0.0-beta2
>     openssl-3.0.0
>     openssl-3.0.1
>     openssl-3.1.0
> 
> This is a little more than just avoiding to change the periods with
> underscores.  However, if you look at the tar files we've released for
> a long time, that's the naming format they use, and I can see benefits
> in having the tags for a release match the tar file of the same
> release:
> 
>     openssl-0.9.7a.tar.gz
>     openssl-0.9.7a.tar.gz.asc
>     openssl-0.9.7a.tar.gz.md5
> 
> Future tar files would be numbered with the new version scheme, of
> course:
> 
>     openssl-3.0.0-alpha1.tar.gz
>     openssl-3.0.0-beta2.tar.gz
>     openssl-3.0.0.tar.gz
>     openssl-3.0.1.tar.gz
>     openssl-3.1.0.tar.gz
> 
> So what about release branches?  We could actually follow a very
> similar new pattern, just replace the last digit with, say, an 'x', to
> signify that this branch will contain a series of patch releases:
> 
>     openssl-3.0.x
> 
> In this branch, one would expect to see the tags 'openssl-3.0.0',
> 'openssl-3.0.1', 'openssl-3.0.2', ...
> 
> Earlier today, I submitted a new release script that codifies exactly
> this:  https://github.com/openssl/openssl/pull/11516
> 
> Thoughts?
> 
> Cheers,
> Richard
> 
> (*) Well, not quite, there was RCS, there was SCCS, and a few other
>     versioning systems that would make your skin crawl by today's
>     standards, even more so than CVS.
> 
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/