: I think we should change 1.3.0 to 1.4.0 for spec version in Solr trunk.
: Thought?
Solr's build file(s) are actually correct.
The spec version of a jar has to be purely numeric ("-dev" is illegal) and
must increase as things change ... so we use the *last* version plus a
long date+time stamp to get a unique version for each successive change on
the trunk. on official releases you bump the "specversion" property up to
indicate that it's an official release. (which is why the 1.3 branch has
it baked as 1.3.0 -- that's the spec version of hte APIs in the jar, only
bug fix/implementation changes will ever be made on the 1.3 branch)
Impl version can be anything, hence a lot of stats about the build are put
there.
If you set specversion to 1.4.0 now, then (in theory) apps that inspect
the versions of jars they load could get confused if any API changes are
made between now and when the official 1.4.0 release comes out -- but
other then some old applet stuff, i've never actually heard of anything
that pays attention to jar versioning and will drive behavior based on
what the specversion says (or how it compares to the spec version of
previous versions) so it's mostly an academic argument.
There is a breif comment about this in common-build.xml (direclty above
where the specfile property is set) and the links in the comment in the
<manifest> task go into a lot more detail about this.
: > Lucene Specification Version: 2.9-dev
: > Lucene Implementation Version: 2.9-dev 779312 - 2009-05-27 17:19:55
...that's definitely broken according to the jar documentation ... but
like i said, it's an esoteric thing to worry about.
-Hoss
