Revisiting tradition: branches and tags

[Richard Levitte]

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
OpenSSL Project         http://www.openssl.org/~levitte/