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
