[rules-dev] [Proposal] Less horrible releases: 1) Don't add new features after CR1 is branched

[Jari Timonen]

Hi,

I think it's a great idea. Also long lasting feature branches should
not exist. Features must be split into smaller merges to the master.
This makes integration easier. This prevents "day before" CR1 mega
merges (with huge amount of conflicts). After CR1 has been branched,
there should be decent testing period.

This all can be achived by split features into smallest marketable features.

-jari

On Fri, Jun 24, 2011 at 7:49 AM, Geoffrey De Smet
<ge0ffrey.spam at gmail.com> wrote:
> Hi guys,
>
> This release (5.2.0) has been pretty horrible.
> We 've lost lots of time on:
> - cherry-picking commits
> - testing everything again and again (and again) because the last
> cherry-picked commit just changed everything again
> Which results in months of delay (branch date was 28-APR and release date
> was 23-JUN).
>
> Let's make the next release less horrible :)
> I believe this organization problem is very easy to fix, by introducing this
> rule:
>   Don't add new features after CR1 is branched (on the CR/final release
> branch)
>
> What do you think? Do you think this is a good idea?
>
> --
> With kind regards,
> Geoffrey De Smet
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>