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

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