: 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
