Re: Proposal about Version API "relaxation"

OK I think a pretty clear proposal is taking shape -- I'll call a vote. We've kinda discussed it to death now... Mike On Mon, Apr 26, 2010 at 8:25 AM, Mark Miller wrote: > On 4/26/10 8:23 AM, Robert Muir wrote: >> >> >> On Mon, Apr 26, 2010 at 8:15 AM, Mark Miller >

Re: Proposal about Version API "relaxation"

On 4/26/10 8:23 AM, Robert Muir wrote: On Mon, Apr 26, 2010 at 8:15 AM, Mark Miller mailto:markrmil...@gmail.com>> wrote: It's not that simple. If you want to commit a patch without having it reverted, you *do* have to do certain things - currently, you have to attempt back compat.

Re: Proposal about Version API "relaxation"

On Mon, Apr 26, 2010 at 8:15 AM, Mark Miller wrote: > > It's not that simple. If you want to commit a patch without having it > reverted, you *do* have to do certain things - currently, you have to > attempt back compat. Or don't commit. You guys seem to think its a free for > all. Its obviously n

Re: Proposal about Version API "relaxation"

On 4/26/10 7:57 AM, Robert Muir wrote: On Sun, Apr 25, 2010 at 4:31 PM, Mark Miller mailto:markrmil...@gmail.com>> wrote: I still don't like "just seeing what happens". What we all agree should be best for users as well as devs is not always going to be in alignment with letting t

Re: Proposal about Version API "relaxation"

On Sun, Apr 25, 2010 at 4:31 PM, Mark Miller wrote: > > I still don't like "just seeing what happens". What we all agree should be > best for users as well as devs is not always going to be in alignment with > letting the chips fall where they may. I don't think seeing whether > committers just d

Re: Proposal about Version API "relaxation"

Maybe we should not make a decision right now? We've talked over the proposals, and there are pros and cons to each, and clearly two sides. I think at this point we just have to "try it", whatever "it" is and see if that works and how it plays. It's like software design - we've played w/ some ideas

Re: Proposal about Version API "relaxation"

On 4/25/10 4:10 PM, Shai Erera wrote: I think that we agree in principal about the policy change. We seem to disagree only on where should the default dev should be: trunk or branch. Right. So why not put it up to the test? Let's declare that all dev happens on trunk. If few features are bac

Re: Proposal about Version API "relaxation"

On Apr 25, 2010, at 4:10 PM, Shai Erera wrote: > I think that we agree in principal about the policy change. We seem to > disagree only on where should the default dev should be: trunk or > branch. I don't think it matters. Just document the decision in the wiki in a Development Roadmap. Maybe

Re: Proposal about Version API "relaxation"

Having read the entire thread as it's come in, my head is spinning. It is hard to keep up with the ideas and proposals. Through out this thread my mindset has changed, more than once. And may change again ;) To that end I'd like to make some end-user observations and thoughts: (I had thought tha

Re: Proposal about Version API "relaxation"

I think that we agree in principal about the policy change. We seem to disagree only on where should the default dev should be: trunk or branch. So why not put it up to the test? Let's declare that all dev happens on trunk. If few features are backported - then it means (probably) that there is no

Re: Proposal about Version API "relaxation"

On 4/25/10 1:43 PM, Michael McCandless wrote: Changes that go into stable need to be merged to unstable, maybe periodically sweeped or maybe merged up by the original committer or likely some combination (like flex). (And, yes we'll still use other branches for big new features that are in acti

Re: Proposal about Version API "relaxation"

Of course - its all a matter of degree. Trunk is not going to be 'super' unstable - of course it will have to compile. It's still going to be mostly like the current trunk and of course pass tests. Stable will just be *more* stable than trunk. We are only using the terms relatively. Stable wil

Re: Proposal about Version API "relaxation"

A clarification - stable/unstable are not really related to the 'stability' of the branch, right? I mean both trunk and branch will be stable in the sense that tests pass and I can safely use either of them. We're not going to start checking in code which is in the middle of dev, does not compile,

Re: Proposal about Version API "relaxation"

OK, so forget that suggestion :) It sounds like the best way to manage the branches is trunk = unstable (X.0 major release), and long lived branch for ongoing stable dev (X.Y.0 minor releases), and possible bug fix branches off of that (X.Y.Z), on demand if needed. But the intention here is not t

Re: Proposal about Version API "relaxation"

> 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 stil

Re: Proposal about Version API "relaxation"

On Sun, Apr 25, 2010 at 11:48 AM, Shai Erera wrote: > > 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. > > This is not very open sourcy :).

Re: Proposal about Version API "relaxation"

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

Re: Proposal about Version API "relaxation"

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

RE: Proposal about Version API "relaxation"

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 or

Re: Proposal about Version API "relaxation"

On 4/25/10 9:55 AM, Robert Muir wrote: On Sun, Apr 25, 2010 at 9:30 AM, Mark Miller mailto:markrmil...@gmail.com>> 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'

Re: Proposal about Version API "relaxation"

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 enfor

Re: Proposal about Version API "relaxation"

On 4/25/10 8:42 AM, Robert Muir wrote: On Sun, Apr 25, 2010 at 8:24 AM, Mark Miller mailto:markrmil...@gmail.com>> wrote: That sounds good to me too. This doesn't sound good to me. It doesn't help anything, except Mark's paranoia about stable getting features. I'm up for the other way

Re: Proposal about Version API "relaxation"

On Sun, Apr 25, 2010 at 8:24 AM, Mark Miller wrote: > That sounds good to me too. > > > This doesn't sound good to me. It doesn't help anything, except Mark's paranoia about stable getting features. And it hinders development and community by creating a fake trunk. We could do the opposite inste

Re: Proposal about Version API "relaxation"

That sounds good to me too. On 4/25/10 6:58 AM, Michael McCandless wrote: Maybe we can leave unstable on its own branch, and stable remains on trunk, like it is today? And, it's not the committer's job to port each little commit to stable over to the unstable branch. Instead, we periodically r

Re: Proposal about Version API "relaxation"

Maybe we can leave unstable on its own branch, and stable remains on trunk, like it is today? 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,

Re: Proposal about Version API "relaxation"

On Apr 22, 2010, at 5:58 PM, Mark Miller wrote: > Well yes - throwing out stable releases and back compat is going to be much > more easy to maintain, but I think that's besides the point... > > Handling our current back compat policy is not something most have wanted to > do for long either -

Re: Proposal about Version API "relaxation"

Well yes - throwing out stable releases and back compat is going to be much more easy to maintain, but I think that's besides the point... Handling our current back compat policy is not something most have wanted to do for long either - that's never been a reason for tossing it. I agree with

Re: Proposal about Version API "relaxation"

Jumping in late, but I have a hard time believing that committing to both trunk and stable is something people are going to want to do in practice for very long. The other proposal (backporting when necessary) seems much more viable and easy to maintain and allows trunk to move ahead. Besides,

Re: Proposal about Version API "relaxation"

> My main problem with devleoping new features on trunk first and then porting > by adding backwards cruft is, that you first don’t care with backwards and > then suddenly have to think about it. This may change the API on trunk > again, to get nearer to backwards or maybe because a backwards layer

Re: Proposal about Version API "relaxation"

Merging a change is far less than double the effort... The first time around you had to type each character yourself, create tests from scratch, fix the failures, post patches, respond to feedback, iterate like crazy, maybe throw it all over and start over, etc. The second time around "svn merge"

Re: Proposal about Version API "relaxation"

Whether such features (that require some amount of back compat "stuff") are done on stable then ported to unstable (trunk), or vice-versa, is something we each can work out / iterate. It'll come down to individual preference, and that's perfectly fine. Some us still use emacs and some of us swear

Re: Proposal about Version API "relaxation"

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, Earwi

Re: Proposal about Version API "relaxation"

On 4/22/10 10:23 AM, Shai Erera wrote: I don't remember a release w/ an empty BW section in CHANGES ... and I think it's healthy. Otherwise, you'll need to wait endlessly until a major version is released until you can use some features that you, yourself, developed (if you need to use a releas

Re: Proposal about Version API "relaxation"

On Thu, Apr 22, 2010 at 10:57 AM, Uwe Schindler wrote: > But you need one, if you want to backwport some feature. My point was, > that if you are planning to backport something, its better to start > developing on stable, as else you can possibly get problems when you only > have a clean API wit

RE: Proposal about Version API "relaxation"

ril 22, 2010 4:53 PM To: dev@lucene.apache.org Subject: Re: Proposal about Version API "relaxation" On Thu, Apr 22, 2010 at 10:48 AM, Uwe Schindler wrote: Hi Robert, My main problem with devleoping new features on trunk first and then porting by adding backwards cruft is, that

Re: Proposal about Version API "relaxation"

On Thu, Apr 22, 2010 at 10:48 AM, Uwe Schindler wrote: > Hi Robert, > > > > My main problem with devleoping new features on trunk first and then > porting by adding backwards cruft is, that you first don’t care with > backwards and then suddenly have to think about it. This may change the API >

RE: Proposal about Version API "relaxation"

; http://www.thetaphi.de eMail: u...@thetaphi.de From: Robert Muir [mailto:rcm...@gmail.com] Sent: Thursday, April 22, 2010 4:11 PM To: dev@lucene.apache.org Subject: Re: Proposal about Version API "relaxation" On Thu, Apr 22, 2010 at 10:08 AM, Earwin Burrfoot wrote: Okay,

Re: Proposal about Version API "relaxation"

Shai. People are free to bash their brains out against back-compat on a stable branch. IF they want. If they don't want, they work on trunk. When stuff is ported from stable to trunk, cruft is removed. When (if) stuff is ported from trunk to stable, cruft is added. The only point Mike's offer diff

Re: Proposal about Version API "relaxation"

I don't remember a release w/ an empty BW section in CHANGES ... and I think it's healthy. Otherwise, you'll need to wait endlessly until a major version is released until you can use some features that you, yourself, developed (if you need to use a released Lucene and cannot satisfy w/ trunk). Sh

Re: Proposal about Version API "relaxation"

On Thu, Apr 22, 2010 at 10:20 AM, Robert Muir wrote: > > I think its *more* <-- sorry, than 1% (flex, etc) that should be excluded > from stable, but thats my opinion. > > -- Robert Muir rcm...@gmail.com

Re: Proposal about Version API "relaxation"

On Thu, Apr 22, 2010 at 10:16 AM, Shai Erera wrote: > But I thought that was the whole point - get rid of Version and loosen on > the bw policy to not be so restrictive on API. We can finally move to use > interfaces, stop that API refactoring and deprecation (as one said on a blog > - "orgy"). I

Re: Proposal about Version API "relaxation"

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 exc

Re: Proposal about Version API "relaxation"

But I thought that was the whole point - get rid of Version and loosen on the bw policy to not be so restrictive on API. We can finally move to use interfaces, stop that API refactoring and deprecation (as one said on a blog - "orgy"). If we adopt Mike's proposal, where does it leave us - 99% of th

Re: Proposal about Version API "relaxation"

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

Re: Proposal about Version API "relaxation"

On Thu, Apr 22, 2010 at 10:10 AM, Robert Muir wrote: > > > On Thu, Apr 22, 2010 at 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

Re: Proposal about Version API "relaxation"

On Thu, Apr 22, 2010 at 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? > > Why wouldnt you commit to trunk, then merge to the sta

Re: Proposal about Version API "relaxation"

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 wrote: > I'd vote -1 on Shai's variation and +1 on Mike's proposal. > > I don'

Re: Proposal about Version API "relaxation"

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 b

Re: Proposal about Version API "relaxation"

On Thu, Apr 22, 2010 at 9:52 AM, Shai Erera wrote: > 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 wil

Re: Proposal about Version API "relaxation"

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/

Re: Proposal about Version API "relaxation"

On Wed, Apr 21, 2010 at 1:56 PM, Shai Erera 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"

Re: Proposal about Version API "relaxation"

Analysis API (like any other public API) definitely should not be broken within a major release. I think we should also minimize the API surface area required of analysis by the indexer & query parser. Eg, indexer doesn't need to know about an analyzer -- instead, it should interact with an itera

Re: Proposal about Version API "relaxation"

On 4/21/10 2:28 PM, Robert Muir wrote: On Wed, Apr 21, 2010 at 2:20 PM, Mark Miller > wrote: What about api back breaks? Seems like an issue when trunk will be free to break. How will you know what versions of analyzers can be used by which versions

Re: Proposal about Version API "relaxation"

On Wed, Apr 21, 2010 at 2:20 PM, Mark Miller wrote: > > What about api back breaks? Seems like an issue when trunk will be free to > break. How will you know what versions of analyzers can be used by which > versions of Lucene? Just a readme? Are their any guarantee's? How will I > know when I ge

Re: Proposal about Version API "relaxation"

On 4/21/10 11:25 AM, Michael McCandless wrote: Trying to summarize what we seem to be roughly converging to, here: * Up front: consolidate all Solr core, Lucene core, contrib analyzers into one place (contrib/analyzers). Don't use Version in there; instead, the released JAR is vers

Re: Proposal about Version API "relaxation"

+1 for developing in a single place (trunk) and backporting on on-demand basis. The other points are fine. On Wed, Apr 21, 2010 at 21:56, Shai Erera wrote: > So basically, API-wise, the stable branch will remain like it is > today: API changes under deprecation path, bw breaks as long as they >

Re: Proposal about Version API "relaxation"

So basically, API-wise, the stable branch will remain like it is today: API changes under deprecation path, bw breaks as long as they are documented in CHANGES etc. Trunk will be allowed to change the API as it sees fit (but still document the changes in CHANGES). Index-format wise, we adopt Doron

Re: Proposal about Version API "relaxation"

Trying to summarize what we seem to be roughly converging to, here: * Up front: consolidate all Solr core, Lucene core, contrib analyzers into one place (contrib/analyzers). Don't use Version in there; instead, the released JAR is versioned. The app picks its required version compa

Re: Proposal about Version API "relaxation"

I like these separate levels, to characterize index compatibility. As far as I know we've never had a level 3 major release :) Mike On Mon, Apr 19, 2010 at 4:28 AM, Doron Cohen wrote: > Late joining... could we agree on an "intention" to provide an index > migration tool when/if format back com

Re: Proposal about Version API "relaxation"

On Fri, Apr 16, 2010 at 1:00 PM, Robert Muir wrote: > And I think backwards compatibility should be more community-driven instead > of a "policy". If no one wants to put things in a stable branch I really do > think thats a sign of something (mostly that its not as important as you seem > to t

Re: Proposal about Version API "relaxation"

The 'unless' part is good and in place IMO. Certainly, if sometimes in the future Lucene moves away from segmented indexing approach into something else, I wouldn't expect a migration tool to be introduced. So overhauling index file format might be ok to go w/o any migration tool introduced. But I

Re: Proposal about Version API "relaxation"

Late joining... could we agree on an "intention" to provide an index migration tool when/if format back comp. has to be broken? It is not clear to me that this was agreed... So here is a suggestion for a revised index format backwards compatibility policy: Starting release 4.0, Lucene has a limite