lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: rough outline of where Solr's going
Date Thu, 18 Mar 2010 18:01:52 GMT

: As you stated modules were important to think about for svn location,
: then it would only make sense that they are important to think about
: for release numbering, too.

I don't think svn location should neccessarily influence release 
numbering, but release bundling certianly should.

if we release "lucene-java-X.Y.tgz" and "lucene-solr-N.M.tgz" on the same 
day from the same trunk, and lucene-java-X.Y.tgz contains multiple 
somewhat independent modules/contribs then they should all certainly have 
the same version number (X.Y) -- but i don't think that neccessarily means 
that X.Y needs to equal N.M.

: So lets say we spin off a lucene-analyzers module, it should be 3.1,
: too, as its already a "module" to some degree, and having a
: lucene-analyzers-1.0.jar would be downright misleading.

I was never suggesting that any version numbers should go backwards and 
reset to 1.0 ... if the only way to get lucene-analyzers-X.Y.jar right now 
is part of lucene-java-X.Y.tgz then they should have identicle version 
numbers.  if we then spin off lucene-analyzers so that 
lucene-analyzers-A.B.jar is now released as it's own artifact 
(lucene-analyzers-A.B.tgz) then A.B should be whatever makes sense as an 
"increment" from the previously released version of lucene-analyzers.

Concretely: if lucene-java-3.5.tgz contains lucene-core-3.5.jar and 
(lucene-analyzers-3.5.jar, and then we decide that we want to start 
releasing lucene-analyzers.jar independently of lucene-java, then the 
rlease should produce *either* lucene-analyzers-3.6.tgz or 
lucene-analyzers-4.0.tgz -- depending on how significant the changes in 
API/functionality are for the users.  This should can be an independ 
decision from wether the next version lucene-java (possible/probably 
released on the same day) is lucene-java-3.6.tgz or lucene-java-4.0.tgz

: So from this perspective of modules, with solr being a module
: alongside lucene, 3.1 makes a lot of sense, and it also makes sense to
: try to release things together if possible so that users aren't
: confused.

I thinks solr-3.1 only makes sense if Solr is include in one big 
giant apache-lucene-3.1.tgz release ... if apache-solr is a seperate 
release artifact then there is no reason to try and unify the version 
numbers (that seems far more confusing to typical users of Solr, who are 
no more worried about the lucene-java version bump in solr then they are 
about the tika version bump, or any other dependency)

-Hoss


Mime
View raw message