Sorry about the previous email, I thought I had closed the message, not hit the send button.
Anyway, my question was in regards to the small changes that I put together for allowing package compilation and snapshot creation in bug GUVNOR-1080. [https://issues.jboss.org/browse/GUVNOR-1080] Will Jervis and/or Toni be backing those out in favor of the larger RESTful implementation proposed here? > http://community.jboss.org/wiki/AtomPubinterfaceforGuvnor Or will the changes be kept in until these ideas can be agreed to and implemented in a later build/release? best wishes, Andrew On Dec 14, 2010, at 9:51 AM, Geoffrey De Smet wrote: > Hi guys, > > Toni and Jervis would like to start working on the release next Friday, > so anything that is committed before Thursday 16-DEC-2010 18:00 GMT (=branch > day) makes the release > and anything that's later does NOT make the release. > At least, that's the general idea :) > If needed, you can ask Toni to port specific commits to the release branch. > Please don't commit anything unstable Thursday, just to get it to ship in the > M1 release. > The release date will be soon after that branch day, but no sooner than it's > ready :) > > > More info > ====== > Release branch: No release is done from trunk (including milestone releases). > Every release set gets a release branch, for example: > drools-5.2.x branch with tags: > drools-5.2.0.RC1 > drools-5.2.0.RC2 > drools-5.2.0 > drools-5.2.1 > drools-5.2.2 > drools-5.2.0.M1 branch with tags: > drools-5.2.0.M1 > drools-5.2.0.M2 branch with tags: > drools-5.2.0.M2 > Branch day: the day (actually a timestamp) on which Toni creates the release > branch as a copy from trunk (master) > Usually 1 or 2 weeks before the aimed release day > For milestones 1 or 2 days can be sufficient > This gives them a chance to test the assemblies and release artifacts and > patch any blocking bugs > without the other developers adding stuff > Compare this to the linux kernel where they can commit for half a month and > the branch day is 2 and half months before the release :) > Stable features can be added before the branch day. Unstable or risky > features must be added after the branch day. > The branch day date is mostly unchangeable for all developers (at least close > to the date): > Postponing the timestamp for 1 developer = blocking all other developers of > adding their risky features to trunk. > In or out principle: > Either your commit is there, before the branch day, and it makes the release. > Either your commit is not there, before the branch day, and it will have to > wait for the release. > Either you convince Toni that there is 100% no risk in adding your commit and > you commit it to both trunk and release branch. > Fight your inner feeling that says "I 'll just add this improvement fast so > it's part of the release. I am sure it's fine." > It might not be fine. It's not worth the risk. > Release date: When the release branch is releasable. It's ready when it's > ready. > The release date is irrelevant for most developers. They should watch the > branch day. > So to put this in effect: > Branch day (timestamp) for M1 Thursday 16-DEC-2010 evening 18:00 GMT. > Either your commit is in there > Or it is NOT > Don’t worry, it will be in the next release > Or you politely convince Toni so you can commit it to both trunk and the > release branch > -- > With kind regards, > Geoffrey De Smet > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
