Return-Path: 
 <solr-dev-return-17508-apmail-lucene-solr-dev-archive=lucene.apache.org@lucene.apache.org>
Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org
Received: (qmail 87166 invoked from network); 21 Jun 2009 02:56:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 21 Jun 2009 02:56:51 -0000
Received: (qmail 472 invoked by uid 500); 21 Jun 2009 02:57:02 -0000
Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org
Received: (qmail 390 invoked by uid 500); 21 Jun 2009 02:57:02 -0000
Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:solr-dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:solr-dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:solr-dev@lucene.apache.org>
List-Id: <solr-dev.lucene.apache.org>
Reply-To: solr-dev@lucene.apache.org
Delivered-To: mailing list solr-dev@lucene.apache.org
Received: (qmail 380 invoked by uid 99); 21 Jun 2009 02:57:02 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Jun 2009 02:57:02 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [208.69.42.181] (HELO radix.cryptio.net) (208.69.42.181)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Jun 2009 02:56:52 +0000
Received: by radix.cryptio.net (Postfix, from userid 1007)
	id 5095B71C2FD; Sat, 20 Jun 2009 19:56:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by radix.cryptio.net (Postfix) with ESMTP id 4D46C71C2BC
	for <solr-dev@lucene.apache.org>; Sat, 20 Jun 2009 19:56:31 -0700 (PDT)
Date: Sat, 20 Jun 2009 19:56:31 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: solr-dev@lucene.apache.org
Subject: Re: Solr Specification Version
In-Reply-To: <4A3D7C1C.6060502@r.email.ne.jp>
Message-ID: <Pine.LNX.4.64.0906201939380.31944@radix.cryptio.net>
References: <4A3C49DC.6010806@r.email.ne.jp> <4A3D7C1C.6060502@r.email.ne.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Checked: Checked by ClamAV on apache.org

 
: 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