+1 for managing git branches the same way as branches were managed in svn (modulo any specific technical differences of git vs. svn). I see only branch_5x in svn right now - when in the staging of release 5.0 was branch_4x deleted?
Looking at the official ReleaseToDo wiki, I don't actually see any process for removing old branches. So what exactly wss the old informal guidance that determined when branch_4x was removed>? BTW, when branchng for a new release, I see this confusing statement: "For the first release in a minor release series - i.e. X.Y.0 - create a minor release branch off the current major version branch, e.g. for minor release 5.5." I mean, shouldn't there be two separate statements, first the creation of the stable branch on a major release, and second the creation of a point/bugfix branch from the stable branch on a minor release? Or have explicit sections for "Major release", "Minor release", and "Bugfix release". -- Jack Krupansky On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <[email protected]> wrote: > Hi, > > Let's keep the branch. The other ones from 3 and 4 are also still there. > > If anybody commits, who cares? If we don't release, it's just useless work. > > If we want to nuke branch, do the same for previous ones. > > Uwe > > Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss < > [email protected]>: >> >> Can't we tag it and then delete the branch? >>> >> >> Any reference. So yes, sure you can. But this doesn't really address >> the second part of my e-mail -- people would still have to issue: >> >> git remote prune origin >> >> and I don't want to fight Uwe over supposedly magical git commands :) >> >> if infra let's us put in any git hooks and protect branches from there. >>> >> >> Yes, this would be another option (but it requires admin-side tweaks). >> >> I'm not convinced we need a new strategy just because we are on git though. >>> We generally don't decide >>> we won't do a release, someone volunteers to put >>> one together when something prompts it. I don't remember protecting >>> branches >>> in SVN and so I wonder if we need to now? >>> >> >> Exactly. We really don't need to do anything other than just agree to >> not commit there... that's part of the reason I wanted more "semantic" >> names for branches -- they're kind of hard to eradicate once created >> in public. >> >> Anyway, as for branch_5x -- no need to protect anything, really. If >> somebody DOES commit something (by accident or otherwise) we can >> always revert those commits (or even force the reference to what it >> was before the mistake, effectively undoing the change). >> >> D. >> >> ------------------------------ >> >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > -- > Uwe Schindler > H.-H.-Meier-Allee 63, 28213 Bremen > http://www.thetaphi.de >
