Dear colleagues,

We would like to perform a cleanup of old/stale branches and tags in our
main repository. We currently have 68 branches and 467 tags, most of
which are no longer used/useful. We'd like to keep only the two active
branches we need for development in the repository, namely 'master' and
'devel', and only meaningful tags, like vX.Y.Z for each version. All
other branches should be short-lived, or in our forks.

I made a backup of the repository in its current state and put it on EOS
to be able to restore any of the branches that are being deleted, so if
a branch you'd like to checkout is missing, please let me know. I will
also keep two branches for backports: v4.12.x and v5.5.x. If you just
want to checkout a release, it's possible to checkout based on a tag.

Starting with v5.6.0, our goal is to have all releases happen linearly
in the history of the master branch, without any duplicated commits on
other branches, so the devel branch serves the same purpose that the
master branch used to serve, where all changes go, and from there I will
pick up commits and release them on master. New features will remain in
devel until the next minor release, but all commits in the devel branch
will eventually make their way to the master branch in a release. Please
see docs/CONTRIBUTING.md for the details.

Since issues are only closed automatically once their related fixes are
merged to master, I am considering to merge bug fixes to master before the
next patch release is out, to make it easier to track progress in the
release milestone. For example, in the milestone for 5.6.2, linked below,
we have 7 open issues as I am writing this message, but 4 of them
already have a fix in devel.

  https://github.com/xrootd/xrootd/milestone/34

By (maybe partially) merging devel into master with a fast-forward merge, 
the issues with merged fixes will automatically close. Only bug fixes
will be merged this way, however.

As for release notes, in this new model we do not need to keep a
PreReleaseNotes.txt anymore, so I will merge it with ReleaseNotes.txt,
and any changes to the release notes can go directly there. However, 
I suggest to just write in the first line of the commit message what you
would like to go in the release notes, and I can build update ReleaseNotes.txt
before each release. This way we avoid issues rebasing commits that
modify nearby lines in the ReleaseNotes.txt file. I usually build the
release notes using git shortlog (try "git shortlog v5.6.1.." to see
what's currently in devel). 

Alright, apologies for the long message, and have a nice weekend!

Best regards,
-Guilherme

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1