: To paraphrase a dead English guy: A rose by any other name is still the same,
: right?
:
: Basically, all the version number tick saves them from is having to read the
: CHANGES file, right?
Correct: i'm not disagreeing with your basic premise, just pointing out
that it can be done with the current model, and that predicable "version
identifiers" are a good idea when dealing with backwards compatibility.
: Thus, the version numbers become meaningless; the question is what do we see
: as best for Lucene? We could just as easily call it Lucene Summer '08 and
: Lucene Winter '08. Heck, we could pull the old MS Word 2.0 to MS Word 6.0 and
well .. i would argue that with what you hpothozied *then* version numbers
would becoming meaningless ... having 3.0, 3.1, 3.2, 4.0 would be no
differnet then having 3, 4, 5, 6 -- our version numbers would be
identifiers with no other context ... i'm just saying we should keep the
context in so that you know whether or not version X is backwards
compatible with version Y.
Which is not to say that we shouldn't hcange our version number format...
Ie: we could start using quad-tuple version numbers: 3.2.5.0 instead of 3.5.0
3: major version #
identifies file format back compatibility (as today)
2: api compat version #
classes/methods may be removed when this changes
5: minor version #
new methods may be added when this changes (as today)
0: patch version #
changes only when there are serious bug fixes
...that might mean that our version numbers go...
3.0.0.0
3.0.1.0
3.1.0.0
3.1.1.0
3.1.2.0
3.2.0.0
...where most numbers never get above "2" but at least the version number
conveys useful compatibility information (at no added developer "cost")
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
