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

[Geoffrey De Smet]

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

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