Archie Cobbs wrote:
- Decide on the version number.
  We had a very small/brief discussion about this during Fosdem.
Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when
  we hit "1.0". So the proposal is to keep using a "sequence version
  number". Either just drop the "0." and make the next release-number
classpath-21, or adopt a year.month style version number and make the
  next version number classpath-6.3 for the March 2006 release.
  In either case we will just use a code name for a release that has
  some special feature set that we are proud of, but we will always
  just increase the release snapshot number. Suggestions or Opinions?

Opinion requested, here granted :-)

Changes in version number format, etc. have a cost in that can
confuse (or at least complicate) packaging and versioning software
like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users).

If all we want is a sequence numbering, then 0.xx has been working
fine so why change it?

If we want to be prouder, let's just release 1.0 and be done with it.
Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness
of "1.0" will fade quickly.

So I vote either keeping the status quo, or releasing 1.0.
A "classpath-6.3" seems to be the worst of both worlds.

I agree with the above but my preference would be for "1.4.x". We are at about 99% of 1.4 API coverage, and we have many features that weren't shipped by Sun until 1.5. When we are in the same situation with respect to 1.5, we should call ourselves 1.5.x and so forth. This makes the situation much more clear to casual users as to what they can expect in terms of features.
--
犬 Chris Burdess
  "They that can give up essential liberty to obtain a little safety
  deserve neither liberty nor safety." - Benjamin Franklin




Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to