This is exactly the intention behind the proposal we are voting on. Big changes, that'd be destabilizing if attempted on the stable branch, would be done only on unstable (= trunk).
More "normal" changes, which can still include deprecations/some back compat, would be done on the stable branch and unstable. So, eg, rather than attempt back compat for a big change like flex, we would instead do it only in unstable and it'd first become "available" in the next .0 release. By segregating the big changes away from stable we should be able to keep stronger back compat on stable. We also save our resources not building costly back compat layers that, because of their complexity, bring their own problems. Also, our release numbers are more "standard" -- the .0 release will have major changes (unlike today where is has no changes except removal of deprecations). Mike On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <markrmil...@gmail.com> wrote: > On 4/26/10 2:43 PM, Chris Hostetter wrote: >> >> My best guess: that what this is really suggesting is that "trunk" >> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0, >> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1., >> 4.2, etc...) happen on "more stable" branches off of the major version >> release branches (ie: branch_3_0 forks off trunk when 3.0 is release, >> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...) > > This is what I would like. Not sure if that's what will come from the > current proposal or not, but seems so to me. > > -- > - Mark > > http://www.lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
