Revisiting tradition: branches and tags

Matt Caswell matt at
Mon Apr 13 08:48:35 UTC 2020

On 11/04/2020 10:53, Dr. Matthias St. Pierre wrote:
> 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.

Yes - this aspect was my main hesitation about the proposed new format,
i.e. the fact that we have a set of existing tags/branch names.
Constantly changing between the new format and the old format as we look
at older branches/tags could be painful. Just creating new tags for all
the existing ones would be one way forward.

Typing OpenSSL_1_1_1-stable and getting all the right upper/lower case
characters in the right place and making sure to use _ vs - as
appropriate is a challenge for my fingers which I constantly fail.

Is it possible to set up alias names for the historical branches?


> Matthias
>> -----Original Message-----
>> From: openssl-project <openssl-project-bounces at> On Behalf Of Richard Levitte
>> Sent: Friday, April 10, 2020 8:28 PM
>> To: openssl-project at
>> 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:
>> 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 Project

More information about the openssl-project mailing list