On 2010/12/15 5:58, Andrew Waterman wrote: > 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? > Hi Andrew, your patch is already on trunk and it can continue to live there. The proposed JAX-RS impl can coexist with the old REST impl. This way we dont have to worry about backward comparability. Of course once the new JAX-RS impl is in place, we can advise users to migrate to the new impl gradually.
Cheers, Jervis > 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: >> o 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 >> o drools-5.2.0.M1 branch with tags: >> + drools-5.2.0.M1 >> o 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) >> o 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 :) >> o Stable features can be added before the branch day. >> Unstable or risky features must be added after the branch day. >> o *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. >> o *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. >> o 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./ >> o 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. >> o Either your commit is in there >> o Or it is NOT >> + Don’t worry, it will be in the next release >> o 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 <mailto: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 _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
