Gang,
I am proposing that we start use a variant of the "Linux Standard" on versioning.
Format: MAJOR.MINOR.MICRO
MAJOR=Incompatible changes either at source or binary level.
MINOR=Feature enhancements, both source and binary compatible with earlier versions in the same MAJOR line.
MICRO=New build.
Furthermore; ODD MINOR = development in progress.
EVEN MINOR = released versions.
WDYAT?
Sounds unsurprisingly linux like.....
Seriously, that looks like it would work well. The Major.Minor.Micro separation is something we have always favored (That is how our Version object is set up). The Odd/Even separation would be new though.
Question on minor/major version increments. It is quite likely that the code between a 3.2 and a 3.3 will be very different. One thing the Cocoon folks do between their minor version increments is "branch" the dev stream. (Actually they have a completely new repository, but if we go SVN, the branch would probably make most sense--they have always had problems with a true branch in CVS).
To keep it straight, would we adopt such a practice here? That way we can easily keep up the "production" build with any bug fixes so that it remains as stable as possible, while any new work happens in the dev stream. That would truly be linux like.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
