My proposed change would be to automate the process, using tags/branches that are consistent across all the repos (regardless of the version of the content in the repo). Earlier this week, I tagged the devstudio sources with a 4.5.1.AM3 tag even though devstudio is at version 11.1.0.AM3, simply because it allows EVERYONE in the aggregation (all the JBoss Tools projects and their myriad versions) to use the same tag for consistency.
If you want tags that are loosely based on the WTP version, eg., 3.10.0.foo, we could use that; if you prefer a global tag tied to the release train version (4.8.0.bar) we could do that too. Point is that with consistency comes predictability, and with predictability comes scriptability & automation. No, this doesn't lead to fear, anger, or the Dark Side. :D
As more and more WTP committers and project leads disappear onto other projects / jobs / commitments, perhaps it's time to look at ways to remove the overhead burden of these manual, repetitive, and predictable steps?
Even with no one having God Mode powers, the uber-PMC or a releng committer could be injected (elected, that is) into all the repos so that a single person could run a bulk script to achieve these changes for each milestone and RC release.
(That's how we ran the show many years ago in Eclipse Modeling project - I just had push rights to MANY repos and could affect bulk changes everywhere.)
If a shared bot is a better option, we could explore creating a shared bot user such that multiple people could use it, perhaps even from a jenkins job, when it's time to push a new tag/branch and update the
repositories.txt file accordingly.
WDYT? Centralized power for distributed time/effort savings?
Nick