You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Mike Squire <mi...@gmail.com> on 2011/07/13 14:22:41 UTC

Solr versioning policy

Hi,

I've noticed that since the 3.1 release new minor version releases have been
happening about every two months. I have a couple of questions:

1. Is this the plan moving forward (to aim for a new minor release
approximately every couple of months)?
2. Will minor version increases always be backwards compatible (so I could
upgrade from 3.x to 3.y where y > x without having to update the
schema/config or rebuild the indexes)?

It might be worth sticking something up on the wiki which gives an overview
of the versioning policy just to clarify things. (I had a look and couldn't
find anything.)

Cheers,
Mike.

Re: Solr versioning policy

Posted by Chris Hostetter <ho...@fucit.org>.
: 1. Is this the plan moving forward (to aim for a new minor release
: approximately every couple of months)?

The goal is to release minor versions "more frequently" as features and 
low priority bug fixes are available.  If there is a high priority bug fix 
available, and and no likelihood of a near-term minor release, then bug 
fixes releases (ie: 3.4.1) will be done (as has always been the case)

This new accelerated minor-feature release approach is possible because 
of the parallel development branches approach that was instituted a while 
back, but once those branches were created it took some time to get the 
test/build/release processes automated enough that devs felt formortable 
releasing more frequently.

There's no hard and fast rule about often releases will happen.  Anyone 
can step up and push for a release if they feel the features are ready.

: 2. Will minor version increases always be backwards compatible (so I could
: upgrade from 3.x to 3.y where y > x without having to update the
: schema/config or rebuild the indexes)?

That has always been the goal, yes.  Sometimes the mechanism for dealing 
with new bugs/features requires making changes to config files and when 
known this is noted in the "Upgrading" section of CHANGES.txt for the 
affected release.




-Hoss