I'm keen on helping us move towards the 3.5 release for this Spring (RC1 3/20/12?).
Unless, there are objections I plan to execute the following early next week: * trim up the roadmap for 3.5 to reflect only work that is in progress or completed. Items currently listed for 3.5 for which no work has been done or is planned will be moved to the wishlist. * fix up JIRA to more accurately reflect the current state (next release is 3.5, move out items that aren't on the roadmap) * target RC1 for 2012.03.20 Thoughts? Sound like a plan? Bill On Wed, Jan 18, 2012 at 1:04 PM, William G. Thompson, Jr. <wgt...@gmail.com> wrote: > On Wed, Jan 11, 2012 at 5:27 PM, Andrew Petro <ape...@unicon.net> wrote: >> Hi, >> >>> Would be great to also hear from Scott and Andrew. > > Scott? Your the only one left who hasn't weighed in. > > Bill > > > >> >> >> 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 >>> <marvin.addi...@gmail.com> 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 cas-dev@lists.jasig.org as: wgt...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
