Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <46F60181-01AB-40BB-AC0C-024DE5ADAA13@activema.com>
From: Colin Hynes <colinh@activema.com>
To: solr-dev@lucene.apache.org
In-Reply-To: <Pine.LNX.4.64.0911251204070.6754@radix.cryptio.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-1--443410324
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Solr 1.5 or 2.0?
Date: Wed, 25 Nov 2009 16:22:27 -0500
References: <C7306A04.6C674%Chris.A.Mattmann@jpl.nasa.gov>
 <Pine.LNX.4.64.0911251124490.6754@radix.cryptio.net>
 <3BDF6C99-D22D-4B53-8DE0-61B45613871F@gmail.com>
 <2748961C-EE64-40E4-AE4E-79EA16D8E5C2@gmail.com>
 <Pine.LNX.4.64.0911251204070.6754@radix.cryptio.net>

--Apple-Mail-1--443410324
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Nov 25, 2009, at 3:09 PM, Chris Hostetter wrote:
>
> : > What would a 1.9 release mean in solr?
> :
> : Dooh -- after hitting send, i realized it would just mean:
> : Whatever we would do for the next release, but say 'after this,  
> old APIs won't
> : be supported'
>
> but even that is still a vague statement: are we talking about the
> internal/plugin Java APIs, or to the user/HTTP request APIs?
>
> this is why we've never tried to suggest that Solr has the same back
> compat policy/concerns as Lucene -- because changes in the Solr Java  
> APIs
> aren't as big of a deal between versions as they are in Lucene -- it's
> changes in the user level API that we should be the most worried  
> about,
> because 95% of the people using Solr don't give a shit about what  
> the java
> internals look like.

In my experience software that has multiple APIs like Solr, will drop  
support for old stuff from either or both depending on what they're  
depreciating, so it would really just be dependent on what's getting  
cut. Having said that, I do think the much larger concern is for the  
user-facing API given that this is where the majority sit.

> like i said: i'd rather we just write the code we think we need to  
> write,
> and change the code we think w need to change, and when we decide to
> release it, we should then ask ourselves "what name/number should we  
> put
> on this release to convey how significant the changes are" ...  
> becuase all
> the version number really is, is a marketing tool for conveying
> information to our users.
>
> -Hoss


The versioning could certainly be done on a release by release basis.  
However, I would offer a word of caution about strange jumps in  
version numbers, as this can just serve to confuse the user base  
(someone mentioned this in a previous message that I can't find at the  
moment).
As an example, take a look at many of the major software companies and  
how badly they've handled versioning jumping between numbers, years,  
code names, etcetera. Which brings me to it being used as a marketing  
tool... It's likely these companies felt the same way, and imho  
they've failed to do it effectively (this comes from years of speaking  
to confused customers).
Versioning is really intended as a tool for identifying a particular  
incarnation of an application and hinting at the level of changes.  
While most users will not have the knowledge to really understand all  
the details they do understand that 2.0 > 1.9 > 1.5 > 1.4 and that  
each of these will have differences and that a jump in the first  
number usually indicates significant changes.
Personally, I think it's a bad idea to think of them as only a  
marketing tool.

Just some thoughts, take them as you will.

-Colin


Active Media Architects, Inc.
World Class Design, Programming & Strategy - Since 1998
http://www.activema.com

1-888-392-4567 toll free
1-586-445-1000 local
1-586-445-2247 fax


--Apple-Mail-1--443410324--