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: > 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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev