On 5/2/25 10:53 AM, Joe Orton wrote:
> 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.
Thanks. This made me rethink my understanding of / reread the git garbage
collection.
And indeed the tag should be sufficient to keep all the commits in these release
branches alive and protect them from garbage collection even if we remove the
branch afterwards.
They would only get lost once we remove the tag as well which should not happen.
>
> 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?
I will proceed this way then. I guess an immediate removal of the release
branch(es)
after a release can be added to the release scripts at a later point of time.
Regards
Rüdiger
