lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Regarding Version Numbers for Major Code Changes
Date Wed, 18 Jul 2012 18:53:45 GMT

: We wanted to now which ones included major code changes for a research project
: (for e.g. were there any major changes from v3.0.1 --> v3.0.2?). I know, it is
: difficult to quantify 'major code changes' but those who have been associated
: with this project for long would have formed some intuitive idea about that.

Dificult to wuantify is an understatement -- it would help if you 
described what *you* consider a major code change forthe purposes of your  
question (ie: is a rafactoring that touches every file but adds no new 
public APIs or functionality a major code change?)

To give you some backround info you may not be aware of...

Lucene & Solr version numbers have always followed a "Major DOT Minor DOT 
BugFix" pattern.  

"BugFix" means exactly what it sounds like: between versions where the 
"Major" and "Minor" numbers are the same (ie: 3.0.1 and 3.0.2) there are 
only bug fixes, and no new features of any kind are added.

The difference between "Major" and "Minor" however has more to do with API 
and Index format compatibility then it does with whether there are 
"major" code cahnges...

  http://wiki.apache.org/lucene-java/BackwardsCompatibility

For example: 1.9.x -> 2.0.x involved very few new features, and 
the majority of the changes was removing deprecated APIs and index 
compatibility with 1.x indexes.

If you want to know what changed between any two versions, you can consult 
the CHANGES.txt files, changes are broken down in terms of features, bug 
fixes, optimizations, etc....





-Hoss

Mime
View raw message