Revisiting tradition: branches and tags

Short, Todd tshort at akamai.com
Mon Apr 13 17:13:08 UTC 2020 

As someone who is currently playing around with QUIC branches based on the tags and branch names, I *always* screw things up while typing. I wouldn't mind if the <SHIFT> key were banned from tags and branch names.
--
-Todd Short
// tshort at akamai.com
// “One if by land, two if by sea, three if by the Internet."

> On Apr 13, 2020, at 1:09 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> On Mon, 13 Apr 2020 10:48:35 +0200,
> Matt Caswell wrote:
>> 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.
> 
> New tags is perfectly possible to do.
> 
>> 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.
> 
> I constantly fail the *current* names.
> 
>> Is it possible to set up alias names for the historical branches?
> 
> It's possible yes.  The hard part is 1.1.1.  There *is* something
> called 'git symbolic-ref', but they can only be added in repos we have
> physical access to, so while can add those on our git server, and they
> will work, we cannot add them in github.
> 
> Ref git help symbolic-ref
> 
> Cheers,
> Richard ( still thinks it's worth making the change with 3.0 )
> 
>> 
>> Matt
>> 
>> 
>>> 
>>> 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/
>>> 
>> 
> --
> Richard Levitte         levitte at openssl.org <mailto:levitte at openssl.org>
> OpenSSL Project         http://www.openssl.org/~levitte/ <http://www.openssl.org/~levitte/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200413/91f49ecf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200413/91f49ecf/attachment-0001.sig>

More information about the openssl-project mailing list