Whether such features (that require some amount of back compat "stuff") are done on stable then ported to unstable (trunk), or vice-versa, is something we each can work out / iterate.
It'll come down to individual preference, and that's perfectly fine. Some us still use emacs and some of us swear by IntelliJ ;) We don't really need to agree on these mechanics, in order to vote on opening up an "unstable" (trunk) line for development. Mike On Thu, Apr 22, 2010 at 11:00 AM, Robert Muir <rcm...@gmail.com> wrote: > > > On Thu, Apr 22, 2010 at 10:57 AM, Uwe Schindler <u...@thetaphi.de> wrote: >> >> But you need one, if you want to backwport some feature. My point was, >> that if you are planning to backport something, its better to start >> developing on stable, as else you can possibly get problems when you only >> have a clean API without any idea how to implement a backwards. > > I don't think we should backport any features that require sophisticated > backwards layers. >> >> >> >> So for features that should be backported, start to plan with backwards in >> mind from the beginning. > > I disagree, I think because Lucene is a library, features should be > developed with the best possible API from a users perspective in mind. I > think this doesn't quite get the priority it should today, as "back-compat > trumps all" despite the fact its broken in every release anyway. > > Then separately, if there is a way to backport them easily, then we should > certainly do it, but not if it require sophistication. instead it should > just wait for the next major release > -- > Robert Muir > rcm...@gmail.com > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
