hossman_lucene at fucit
Jul 18, 2012, 11:53 AM
Post #2 of 2
(157 views)
Permalink
|
|
Re: Regarding Version Numbers for Major Code Changes
[In reply to]
|
|
: 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
|
