 |
 |
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