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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
