I agree that deleting EOM branches is the best approach (with tags). Having a branch for an EOM line doesn't make sense since a branch signifies (and/or promotes) active development. Having a tag signifies that this line is static and is a point-in-time pointer to the branch. In the worst case scenario, we can still create a branch off of the tag if we want to 'revive' the branch.
This also simplifies life for committers as it will be easier to know which branches are 'active' since those will be the only branches that exist. On Mon, Jul 15, 2019 at 8:12 AM Wellington Chevreuil < [email protected]> wrote: > I think delete EOM branches and keeping only tags sounds reasonable, but > ain't much experienced on releases management, honestly. Do we know what's > the standard among most apache projects? Maybe we could follow those? > > Em seg, 15 de jul de 2019 às 15:27, Josh Elser <[email protected]> > escreveu: > > > (Sending this note for Busbey as he's chasing other stuff) > > > > He had sent a note to private asking what had happened to branch-1.2. In > > my cleanup of old branches to try to reduce our Jenkins usage at the > > request of Infra, I created a git tag instead of the branch: branch-1.2 > > was deleted remotely, and the tag branch-1.2-EOM was created. > > > > Busbey said he would put back branch-1.2 (at least temporarily), but > > that we should discuss what we want the "normal" to be going forward. > > > > I can see the confusion in folks who are "used to" the "branch-x[.y]" > > notation being confused when the upstream branch is no longer present. > > However, I can also see the "EOM" tag for the same "branch-x[.y]" being > > self-explanatory (or at least a good indication that maybe a user is > > trying to interact with a development line that we no longer maintain). > > > > How do others think we should handle branches which we voted on > > no-longer maintaining releases for? > > > > - Josh > > >
