Right, I think the default should be that ongoing changes go onto the stable branch.
And the exception is if back-compat is too hard/risky to accomplish, we argue for doing it only on trunk. This discussion can take place up front -- the issue's Version will be set accordingly -- and revisited as the issue is developed (eg if back compat turned out to be trickier than we first thought). Mike On Thu, Apr 22, 2010 at 10:04 AM, Mark Miller <markrmil...@gmail.com> wrote: > I'd vote -1 on Shai's variation and +1 on Mike's proposal. > > I don't think features should be backported to stable on request. If we go > this route, I think it should be a matter of course unless the feature is > hairy enough to warrant unstable. > > Saying we should do all dev on unstable, and only back port on request (who > will police that? everyone will accept all requests?) and that we should > just release trunk more often to accommodate, is like saying, lets just > throw back compat out the window, every release will be free to break back > compat, we will just release more often... > > Working on two branches won't be 100% joy, but loosening the existing much > larger annoyance of back compat is not going to be free IMO. To me, Shai's > proposal is essentially - lets keep everything the same, but release more > often (we have decided to that 100 times) and lose back compat requirements. > Then if a dev takes pity on a user, perhaps one of the unstable releases > will get a backport of a feature. > > If we take that route, I am vehemently against changing our policy. > > On 4/22/10 9:52 AM, Shai Erera wrote: > > I was advocating that we always develop on trunk w/ no back-compat support, > API-wise ... you could have developed flex w/ no bw support. > > Currently what you're proposing would cause most features to be developed on > stable w/ bw support and trunk w/o. I propose to leave 'stable', develop on > trunk w/ no bw support (except for index format) and back port features "on > demand" to stable w/ bw support. > > So instead of forcing all development to go through stable + trunk, I > propose to go through trunk, and back port to stable only if requested. In > the end we'll be in the same position (trunk having all features) except for > stable which will include just those features of interest to other people. > > Shai > > On Thu, Apr 22, 2010 at 4:12 PM, Michael McCandless > <luc...@mikemccandless.com> wrote: >> >> 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 >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
