On Wed, Apr 21, 2010 at 1:56 PM, Shai Erera <ser...@gmail.com> wrote:
> The only downside is that we will need to do everything twice: once on > stable and once on trunk. I still think that most of the issues and > development don't affect bw at all and thus we'll always say "this > needs to go to stable and trunk" which will just be an annoyance and > complicate the life of the developers even more because not only will > we need to keep bw compat, we'll need to write the code for trunk as > well. Well, most things. Some features (eg flex would've been such a feature) will only happen in trunk. But, yes, this is a downside -- stable changes will have to be merged up to trunk. > What if we always develop on trunk, release it more often, and if > requested or a committer needs it, we backport a certain feature to > stable? This is what we do today, and I think what's broken about it is we are unable to make a big change that has major breaks from the start. Every big change is required to land on trunk with back compat intact. This is terribly costly for changes like the new analyzer API (Token -> AttrSource migration), and flex. So with the new model, a big change like flex could land on trunk with no back compat, and age for a long time, along with other such changes, before being included in a major release. I'm not sure we'll release trunk (major releases) more often. I think it could go both ways... For small changes, I think whether a given dev works on trunk and merges back to stable, or stable and merges forwards to trunk, is an individual choice... Mike --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
