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

[Jervis Liu]

On 2010/12/15 5:58, Andrew Waterman wrote:
> 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?
>
Hi Andrew, your patch is already on trunk and it can continue to live 
there. The proposed JAX-RS impl can coexist with the old REST impl. This 
way we dont have to worry about backward comparability. Of course once 
the new JAX-RS impl is in place, we can advise users to migrate to the 
new impl gradually.

Cheers,
Jervis


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