Hi Guys, The process should be as formal as the community dictates, but I can't help but make the observation that increments in version numbers that are strange to those with some knowledge of artifact versioning will only be stranger to those without (i.e., adopters/users of SOLR).
To me, to jump from 1.5 to 2.0 should include at least 5x the differences (improvements, bug fixes, new features, etc.) between SOLR 1.3 and 1.4, or better yet 6x the differences between 1.4 and 2.0. Is this going to be the case? If not, the 0.6 increment in version numbers is arbitrary (why not release the next SOLR as SOLR 10.0 then?). You could argue that if SOLR 2.0 includes a new major version of one of its principal components (Lucene-java), then this warrants those 6-fold differences. Or, if SOLR 2.0 is an entirely different branch of development and then I would expect to see if developed as such and then watch trunk development go on (1.5, 1.6, 1.7) as incremental improvements to 1.4 until the 2.0 branch is ready to be merged back into the 1.x trunk. On the other hand, I've seen that SOLR is not Lucene and there is a strong sentiment in the SOLR community to that point, so if that's the case, shouldn't the release cycles (and versioning) be a bit more loosely coupled? Insulation is the key. For example with some of the GeoSOLR work going on, I know Grant is looking at how to implement code in SOLR land (e.g., CartesianTierFilter) that exist in Lucene contrib/spatial already, but perhaps SOLR has slightly different use cases or needs for this code, or improvements to make outside of the Lucene release cycle/process. This is just one example: I'm sure there's more. I'm -1 for writing up a formal 50 page document on versioning and SOLR releases, but a few paragraphs and a formula for how to calculate releases on the SOLR wiki - that's probably going to be something valuable to the community, and more importantly, something that's needed to understand and guage the SOLR software product, so +1, and my encouragement, for that. My 2 cents, Chris On 11/25/09 11:54 AM, "Ryan McKinley" <ryan...@gmail.com> wrote: On Nov 25, 2009, at 11:30 AM, Chris Hostetter wrote: > > : > The point being: it's all been very informat up to now -- and > that's > : > probably for the best. "policies" should evolve over time based > on real > : > world situations that come up, and we're still in the process of > doing > : > that. > : > : Agreed, but now that the elephant has been identified in the room, > let's > : come up with a policy then. What are your thoughts on my proposal > (specified > : earlier in this thread)? > > The elephant has been identified, and he's in the room, but he's in > the > far corner and he's not bothering anybody. > > my personal preference (at the moment) is to leave things undefined > for > now ... i'd rather see us get to a point where we say "whoa, here is > an > actaul in the flesh cross roads where it feels wrong to release w/o > bumping the major version" and then to try and write down a policy > ahead > of time anticipating what that cross road is and how we we'll want > to deal > with it. > > if it's unspecified, it can be specified later when it actaully > becomes an > issue -- if it's specified, then people will feel like we are > beholden to > the specification, even if it doesn't wind up making as much sense in > practice. > > (yonik: you're anarchist ways clearly rubbed off on me at apachecon) > I agree with keeping it informal (for now) I agree with Mark that yes, we should do what we can to make the best choices about changes that affect compatibility. For sure. The thing about the 1.5/1.9/2.0 question that makes me uncomfortable is that it is applying the same 'official' rules from lucene to solr. I am not sure how well that maps in practice. What would a 1.9 release mean in solr? (I don't really want an answer, I just don't think it means the same thing in solr vs lucene) Again, i have nothing against calling the next release 2.0 -- I just think that 1.5 is also fine and keeps the door open for 2.0 to be a more fundamental change in solr (that may or may not happen) ryan ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
