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?
Matt
>
> Matthias
>
>
>
>> -----Original Message-----
>> From: openssl-project <openssl-project-boun...@openssl.org> On Behalf Of
>> Richard Levitte
>> Sent: Friday, April 10, 2020 8:28 PM
>> To: openssl-project@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 levi...@openssl.org
>> OpenSSL Project http://www.openssl.org/~levitte/
>