On Fri, Apr 25, 2025 at 12:07:22PM +0200, Ruediger Pluem wrote: > I currently try to update our release scripts to work with git / > Github instead of Subversion, but I get a little bit stuck. The main > reason I get stuck is the technical difference of tags between git and > Subversion. Currently we create release tags / candidates in > Subversion which we use as small / short branches to which we commit a > small amount of changes e.g. the changes in include/ap_release.h. Once > we have done this on the final candidate we never touch this branch > again. We consider it a tag now. > > Doing the same with git would mean that we also would need to create > branches for release candidates and then tag the final commit on these > branches appropriately. Renaming and removing of stale intermediate > candidates would also work with git even though it is not that > straight forward as with Subversion. But in the end we would have a > tag for each release plus a branch. This has the potential to bloat > our branches in git. Hence my question is if we want to continue this > approach or if we want to use a different approach. And if we want to > keep this approach do we want to prefix the names of these release > branches with e.g. 'release/'?
I think a branch is just a label for a particular part of a git tree, so it's possible to delete the branch in the sense you can remove the label, and it doesn't really change anything / lose any of the underlying commit history. So we could continue to use short-lived branches and remove the labels to stop them polluting the branch list if we wanted. Using branches under "release/2.4.<x>" names seems sensible to me. I would start off by keeping the branches post-release, we could always come back later and delete them if we decide it's not necessary to keep them. Or we could delete them when they're a year old or something? Thanks a lot for working on this! Regards, Joe
