lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Proposal about Version API "relaxation"
Date Sun, 25 Apr 2010 16:01:01 GMT
On 4/25/10 11:48 AM, Shai Erera wrote:
> I think that it's a bit naive to think that stable and unstable will
> remain that close to each other such that merging them every so often
> is going to be an even remotely easy task.
> Mark - you recommend that we look at other projects and how it's done
> there. Well, I don't know too many open source projects, but I've
> participated in several products development. From my experience
> there, after a release is cut, a new branch is created (for that
> release). All new development happens on the next release's branch
> (trunk in our case) and usually only bug fixes are developed on the
> previous branch (and often on several such branches). Sometimes, a new
> feature/enhancement which is being developed on trunk is pulled to the
> previous branch on demand.

That really depends on varies. If you want to look at what others do you 
can probably find close to whatever you want. Just remember that Lucene 
is a library.

> Now, backward compatibility on trunk is a must, but at a slightly
> different level than we know it. The customer must be able to upgrade
> his env. to the newest release  w/o losing functionality. Exceptions
> are allowed, but they have to be well documented.
>  From what I see, we behave very much like a product. The new release
> is always bw compatible, exceptions are allowed when they are well
> documented, and no one makes any decisions lightly around here.

I think we behave like a widely used library.

> This is not very open sourcy :). No one here gets paid, we don't share
> Lucene dividents w/ the committers and contributors ...

I don't follow...

> I'm not saying that we should throw back compat out the door entirely,
> but some relaxation must be allowed … today, trunk is already back
> compat w/ exceptions. Can't we decide instead of developing on two
> branches that we will sometimes allow for larger bw breaks, when it
> makes sense? Why are we trying to have an "all or nothing" here?

If you follow what I have argued, this makes no sense. When did I ever 
say all or nothing? I'm so far from that, I just don't know what to make 
of this paragraph.

> And Mark, as soon as we allow trunk to break loose, it won't be like
> merging flex and trunk today - both were developed w/ bw support in
> mind …

Most patches are not that difficult to port. Back compat with flex was 
many times two different paths. So you would merge changes almost in two 
steps - first almost without considering back compat, and the back 
compat way. The flex branch experience tells us a lot about how things 
might work with different branches in the future. The situations won't 
be identical, but there is certainly a lot of overlap. IMO most patches 
will be easy to handle - much easier than dealing with the old back 
compat "policy".

> One other option - let's adopt the way of projects like Java. You
> don't see every 1.6 feature being ported to 1.5 right? Not every 7
> gets to 6 … rather, developmen happens in parallel on several
> branches. Each is fully managed on its own and at some point some
> versions are simply not supported anymore…

This works better with larger projects. This could be a first step 
towards such a world, but with the number of devs we have, starting at 
two main branches seems like a good starting point.

> it would make a lot of sense to declare flex as 4.0, along w/
> analyzers, parallel indexing and even incremental field updates. It
> doesn't mean though that every new feature that is contributed to
> trunk MUST be backported to 3.x. It can be done on demand, on a
> volunteering basis or simply an interest. We may also want to prevent
> such a thing from happening for several features …

I don't agree with that obviously. This is what I argue against.

> Just tossing ideas …
> Shai
> On Sunday, April 25, 2010, Mark Miller<>  wrote:
>> On 4/25/10 9:55 AM, Robert Muir wrote:
>> On Sun, Apr 25, 2010 at 9:30 AM, Mark Miller<
>> <>>  wrote:
>>      Could you elaborate on "it doesn't help anything"? That's an
>>      interesting argument, but not very persuasive :) "It doesn't help
>>      anything other than easing Mark's paranoia" :)
>> The only "advantage" to this idea is it seems to try to enforce putting
>> features in stable, but thats stupid. At the end you still have two
>> branches, you can call whichever one trunk you want, it doesn't really
>> matter. if someone doesn't want to do the work to backport something to
>> stable, they just aren't going to do it.
>> I may be misunderstanding, but this sounds like a call for "free for all" because
everyone will do what they want anyway. But that's not generally how things work. Devs don't
do whatever they want. They largely stick to some common practices (largely back compat).
Not everyone has always agreed with how things have worked, but most have, and it has framed
>> I think you take policy too seriously. From what I was told, our back compat policy
was simply extracted from an email from Doug when in the early days of Lucene. It's just happened
to have made its way to the wiki, and enough devs have tried to stick to what it says. It's
not some all powerful policy - we have subverted it all the time - but it has framed development
and created a lot of really good Lucene releases that where pretty easy to migrate across.
People have generally agreed on the back compat policy due to a large amount of discussion
in the past. Its been argued back and forth, but to a large extent we have stuck with it for
whatever reason. There is no doubt its had a powerful affect on Lucene over the years, whether
positive or negative is up for debate, but I've been pretty happy with how Lucene has progressed
myself. Now it looks like its time to change how we frame development, but I don't find myself
thinking, "who cares how we do it - devs will do whate
ver they want anyway". Because they won't. They will do what the majority of others are doing
- so as we talk about making this change its important to learn which way the other devs are
leaning, and hammer out some common goals. Figure out a little consensus. If I'm the only
one that's "paranoid" about this, doesn't seem you have much to worry about.
>> It would be easy to see different results from this change - we could go the way
some are talking about and do very few back ports to stable, and essentially every release
breaks back compat as it wants. Or we could concentrate more on stable releases, while doing
more radical dev on trunk. It almost sounds to me that you think that it doesn't matter which
way people prefer, because everyone will do what they want anyway. Well I disagree. I think
its important to discuss which way we may end up with, because I think one of the ways is
better for Lucene - and I don't think devs do whatever they want. The general common agreement
about how things are done largely drives what devs do. We are talking about changing that
agreement - I don't have paranoia - I want to discuss where we will end up because I think
its an important change to Lucene, and its important to try and see how different devs feel,
and what frame of mind they are going to go into this with. That will help gu
ide what actually happens. I know you don't think that's important, and I apologize for disagreeing
with you.
>> i'm waiting for the proposal
>> that adds some "policy" about this, that would be very lucene-like.
>> Yeah, because Lucene has so many polices. The backcompat policy is called 'policy'
for convenience - its never been voted in, its not an 'official' policy, we break that policy
all the time. Its more consensus on how things are done than policy - you've seen that by
now I hope. This discussion is also about coming up with consensus. I''m going to call you
paranoid about policies in a minute :)
>> and for any feature where someone is willing to do the work for it to be
>> in stable or unstable, its gonna have to be committed twice, by someone,
>> somewhere.
>> Yeah, well sounds like right now we have a couple options to talk about - consensus
that we generally commit to both at the same time, or consenus that we merge occasionally
instead. The models actually have a lot of differences. And likely there would be some mergers
that did it often (like with flex), so that fewer devs might be backporting. The other way
you would generally be counted on to back port all your own stuff.
>> --
>> Robert Muir
>> --
>> - Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

- Mark

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message