Re: Update of release scripts to work with git / Github instead of Subversion

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