Re: [rules-dev] [Proposal] Less horrible releases: 1) Don't add new features after CR1 is branched
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev