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 // tsh...@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 <levi...@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-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/ >>> >> > -- > Richard Levitte levi...@openssl.org <mailto:levi...@openssl.org> > OpenSSL Project http://www.openssl.org/~levitte/ > <http://www.openssl.org/~levitte/>
signature.asc
Description: Message signed with OpenPGP