FWIW, here's a great read about one possible Git branching model and a Git extension to support it called git-flow:
http://nvie.com/posts/a-successful-git-branching-model/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ Food for thought. Cheers, Dmitriy. On Wed, Jan 11, 2012 at 5:27 PM, Andrew Petro <[email protected]> wrote: > Hi, > > > Would be great to also hear from Scott and Andrew. > > > I agree that I think the current state is master branch is marching > towards 3.5, and 3.4. x branch is maintenance for 3.4.x marching towards > 3.4.12, and 3.3.x branch stands ready as the place to work on, say, a > critical fix for 3.3.x. > > > Since CAS developers need to collaborate on working towards a 3.5 release > today, and since master is the place for that work, a 3.4.x maintenance > branch is necessary and useful today, prior to a 3.5 release, insofar as > work needs done towards a 3.4.12 release. I do think a 3.4.12 maintenance > release is going to be warranted, and I see in JIRA items already slated > for it: https://issues.jasig.org/browse/CAS/fixforversion/11696 > > Three issues are tagged as resolved for 3.4.12: > > https://issues.jasig.org/browse/CAS-1068 > https://issues.jasig.org/browse/CAS-1077 > https://issues.jasig.org/browse/CAS-1066 > > Commits to address these are in master, but they aren't in the 3.4.x > maintenance branch. > > So if a 3.4.12 were tagged from the maintenance branch, it wouldn't > include these fixes. > > These changes need committed to the 3.4.x maintenance branch so that > they'll be included in 3.4.12 whenever it is cut? > > > > >>> * 3.4.x - dev branch for a point or security release of the 3.4.x line > >>> once a new minor version is cut (e.g. 3.5) > > I agree that, ideally, going forward, maintenance branches should be > created only when necessary. I think the 3.4.x maintenance branch is > necessary. > > I don't agree that the trigger for maintenance branch creation is a minor > release (e.g. 3.5). I think the trigger for creating a maintenance branch > should be a need to do something other than work suitable for a patch > release in master and a concurrent need to march towards a patch release. > As in, after 3.5 is released, the trigger for creating a maintenance > branch for 3.5.x should be a commit to master representing work towards > 3.6, that is unsuitable for inclusion in a 3.5.x release, and also a need > to march towards a 3.5.x release. At that point, branch from the latest > 3.5.x tag to create a 3.5.x maintenance branch, and march that towards > 3.5.x patch releases. New work gets committed to master (towards 3.6) and > if applicable also committed, appropriately factored, to 3.5.x branch > towards the next 3.5 patch release. > > As I understand it uPortal is doing something similar on the release of > uPortal 4, wherein a separate uPortal 4.0.x maintenance branch was not > created immediately. uPortal master is marching towards uPortal 4.0.3 > (with the 4.0.2 patch release already out). A 4.0.x maintenance branch > will be created when commits are ready for master that will make it diverge > from uPortal 4.0.x patches to march towards uPortal 4.1. > > > > Andrew > > > > > > > > On Jan 11, 2012, at 1:46 PM, William G. Thompson, Jr. wrote: > > > On Wed, Jan 11, 2012 at 12:53 PM, Marvin Addison > > <[email protected]> wrote: > >>> * master - dev branch of the next release (currently marching towards > 3.5) > >>> * 3.4.x - dev branch for a point or security release of the 3.4.x line > >>> once a new minor version is cut (e.g. 3.5) > >>> * 3.3.x - dev branch for a point or security release of the 3.3.x line > >> > >> That's where we landed with very loose agreement, very little > >> experience and no documentation to drive how it works in practice. In > >> practice no one is maintaining 3.3.x. > > > > Glad we're on the same page! Would be great to also hear from Scott and > Andrew. > > > > > >> I was intending to merge > >> everything from master into 3.4.x since afaik there are no features > >> inconsistent with a 3.4.12 release (i.e. nothing "earth shattering"). > > > > The Roadmap points to a few features that are not consistent with a > > point release. For instance, CAS-1032 would change default behavior > > consistent with a minor release and CAS Service Registry Improvements > > seems like a fairly big change/improvement to warrant a minor release. > > EhCache module is also on master. - > > https://wiki.jasig.org/display/CAS/CAS+Roadmap > > > > At this point, it might be sufficient to roll with a 3.5 in the next > > couple of months and reserve cherry picking features for 3.4.12 > > release if there's enough pull and desire. > > > > > >> > >> With current development practices, all we have to guide what goes > >> into maint branches is the roadmap, which in practice for day-to-day > >> commits leaves a lot of room for interpretation. The maintainer's > >> opinion to be precise. I don't see any other solution that's > >> ultimately not up to the perspective of some developer, but I would > >> argue that the branch maintainer ought to be the authority on what > >> commits are merged into a branch. > >> > >>> 3.4.11 was tagged on master, and at that time 3.4.x should have been > >>> brought up to par with that tag, correct? > >> > >> I did that. > > > > Excellent! > > > > Thanks, > > Bill > > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
