[rules-dev] Branch day for 5.2.0.M1: next Thursday 16-DEC-2010 18:00 GMT

[Andrew Waterman]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101214/bfdcdc4d/attachment.html