lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: Proposal about Version API "relaxation"
Date Thu, 22 Apr 2010 14:17:09 GMT
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 <
lucene@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 <markrmiller@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
> > <lucene@mikemccandless.com> wrote:
> >>
> >> On Wed, Apr 21, 2010 at 1:56 PM, Shai Erera <serera@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-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