lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Proposal about Version API "relaxation"
Date Sun, 25 Apr 2010 15:32:21 GMT
Hi Mike,

> Maybe we can leave unstable on its own branch, and stable remains on
> trunk, like it is today?

This somehow reverses the idea behind the folders in SVN. Everybody looking for the latest
and coolest things would always look in trunk, never in a branch. Almost all projects have
the orginal SVN structure: in A branches folder they do stable development and in trunk the
newest things.

>From the view of the merging its not different at all. For the SVN below the folders trunk,
branches, tags are just folders no other meaning. These folders are some standard way to maintain
an svn repository and we should do it like that. Merging works always, regardless of how you
structure the dirs. You can even merge two branches or whatever.

So I am -1 on this and I am +1 on simply creating a stable branch like it always was and everybody
exspects. The only difference to the past is, that we no also do development on the stable
branch.

> And, it's not the committer's job to port each little commit to stable
> over to the unstable branch.  Instead, we periodically re-sync stable
> --> unstable, like we did with the long-lived flex branch.
> 
> So, then, little would change on how stable is developed, today.  And
> stable would still be the primary source line for development.

That is also true for a branch. See e.g. PHP development. They have a trunk but at the moment
nobody commit there (including me), we are maintaining branches 5.2 and 5.3 at the moment.

> Unstable changes would happen on the unstable branch, and only be
> merged back to trunk when it's time for the next major release.

See above.

Uwe

> On Thu, Apr 22, 2010 at 11:31 AM, Mark Miller <markrmiller@gmail.com>
> wrote:
> > Right - that sounds good to me. And when its a hairy change to back
> port, or
> > the change is just really invasive, or breaks back compat in way you
> have to
> > jump over hoops to put into stable - then you just put it in
> unstable. But
> > generally that is not most changes.
> >
> > On 04/22/2010 10:08 AM, Earwin Burrfoot wrote:
> >>
> >> Okay, let's live with parallel development, but make sure we
> 'always'
> >> port things from stable to trunk, and 'always' remove possible
> >> back-compat layers when doing such a port?
> >>
> >> On Thu, Apr 22, 2010 at 18:04, 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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > --
> > - 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