On 25 Apr 2025, at 11:07, Ruediger Pluem <rpl...@apache.org> 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/'?
My first thought is how much of the ecosystem out there breaks by changing this. Distros rely on us doing things in a certain way to detect updates, etc. Second is does this now rely on us having Github accounts? Github and Apache are separate organisations, and mixing them is not good. Regards, Graham --
