Revisiting tradition: branches and tags

Dr. Matthias St. Pierre Matthias.St.Pierre at
Tue Apr 14 14:04:43 UTC 2020

> > We change the GitHub setup such that pull requests to stable
> > branches need to be based onto the new-style branches, but keep the
> > old-style stable branches in sync with the new-style branches for a
> > little while.
> Er...  how do you change that Github setup?  I thought it simply
> showed a list of all available branches regardless.  So if we got a
> duplicate set, it's going to show both, isn't it?  Considering that
> the github repo is a --mirror of the repo, I'm not
> sure how the old branch refs would be filtered out...

You are right, I thought it was possible using protected branches, but that
doesn't seem to be the case.

> It seems to me like this discussion is splitting into two:
> 1)  Start with new names for 3.0 and on (I can only see positive
>     responses so far, even with Matt's hesitance)
> 2)  Rename of the old names.
> As far as I can see, those two don't have to be in absolute sync, even
> though that would be desirable.  In other words, we can figure out the
> details of 2 even after we've started 1.


The best thing would be to publicly announce the branch renaming in a blog post
with a sufficient notice time  (3-6 months) and with detailed instructions
how to rename the local branches and how to reset the upstream branches
(using `git branch --set-upstream-to=...`). Just as we did for the grand code 
reformatting. We might even provide a smart helper script for users to do the
local conversion.


More information about the openssl-project mailing list