lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Date Tue, 27 Apr 2010 03:25:07 GMT
My understanding is that "Joe Contributor" will not be forced to prepare a
patch against "stable", but will be appreciated if he does :).

The mechanics for "Joe Committer" is undecided yet. What's clear is that Joe
cannot say "I don't care about stable for this issue, therefore I cannot
backport it". The decision on backporting will be done per issue/patch.
Whether it will be backported immediately (as part of that issue), or later
on as part of a periodic stable/trunk sync, is undecided yet.

A minor correction:

> they do stable or vice versa
>
there is no "stable or vice versa" - everything must be put on trunk (unless
it really doesn't belong there, because e.g. the API no longer exists). Many
things will most likely get backported to stable.

Shai

On Tue, Apr 27, 2010 at 12:46 AM, Grant Ingersoll <gsingers@apache.org>wrote:

> +0.9
>
> What are the requirements of me, "Joe Committer" and of "Joe Contributor"
> in regards to submitting/committing patches?
>
> For Joe Committer, am I required to put everything on stable and trunk or
> can I just pick trunk and if someone else wants it they do stable or vice
> versa?
>
> Likewise for Joe Contributor, must I generate two patches now?
>
>
> On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote:
>
> > 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 <markrmiller@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Mime
View raw message