lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@osafoundation.org>
Subject Re: version issue ?
Date Wed, 01 Mar 2006 00:42:29 GMT

On Tue, 28 Feb 2006, Doug Cutting wrote:

> Andi Vajda wrote:
>> Understood. What threw me off was the 'rc1-dev' part of the version on the 
>> branch. I'd expect it to say 1.9 or 1.9-final since the .jar files produced 
>> by a 1.9 branch checkout all say 1.9-rc1-dev even though the branch is past 
>> that now.
>
> Previously I've always incremented the version before making the release, and 
> this always seemed to confuse folks.  This time I tried not incrementing it, 
> and that seems to confuse folks too!
>
> My one concern is that I don't think code that folks download should build 
> something called 1.9-final, as that could be confusing: we should reserve 
> names that sound like real releases for real releases, compiled with the 
> correct JVM, etc.
>
> If you have strong feelings about what should be in these I'd love to hear 
> them!

No particularly strong feelings here, I understand the trade-offs now.

It would seem to me that the source code snapshot that is made to release 
'official' source and binary tarballs on the Lucene website should correspond 
to a precise svn version and that that version's common-build.xml should 
reflect the release number, ie 1.9 or 1.9-final in its "version" property.

If the 1.9 branch were to be modified for making, say, a 1.9.1 release, the 
first change should be in common-build.xml for the version to say something 
like 1.9.1-rc1-dev.

What is the use case here ?

PyLucene is built by first 'svn exporting' a given svn version of the Java 
Lucene trunk or branch. That svn version is hardcoded in PyLucene's Makefile 
and changed everytime PyLucene catches up with Java Lucene which happens a lot 
more often than official Java Lucene releases. The LUCENE_VER variable 
compiled into PyLucene reflects the version names of the .jar files and hence 
the version value in common-build.xml.

It is no problem for me to patch common-build.xml for the 1.9-final release of 
PyLucene from Java Lucene, made from the lucene_1_9 branch, and then revert 
back to the trunk, without the patch, for the future ongoing 2.0 dev builds 
and PyLucene releases.

Andi..

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message