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