Correction Mike - "ongoing changes go onto the stable AND trunk branches" ... let's make it clear.
Shai On Thu, Apr 22, 2010 at 5:15 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > 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 > >
