Danny Angus wrote:
PMC,
We need to have a short term plan for defect fixing, a medium term
plan for enhancements and a long term plan for more radical changes.
We should be able to predict what the number of that release will be.
We do not require extended terminology to express these concepts.
We should talk about "the next major release" and "the major release
following the next major release"
We have problems deciding what should and shouldn't go into a
particular release, but this isn't solved by inventing names.
Please indicate by expressing your vote in the normal manner whether
you agree that in order to foster common understanding the following
terminology should be used in STATUS, VOTE, PROPOSAL and discusions.
The version names, numbering, and meanings described below reflect our
need, they should be adopted as normative terminology by the PMC, and
no other names, numbering or meanings have any formal role in the
management of the James project or its sub-projects.
In this scheme:
X - represents the major version number
this increments when major
or significant incompatible changes are introduced.
Y - represents the minor version number
This increments when new significant features or
functionality is introduced.
Z - represents the maintenance patch release increment
Represents the sequence number of a release of defect fixes
and minor enhancements to existing feature or functionality
Modifiers such as "a - alpha" or "rc - release candidate" should be
used to support the product lifecycle.
The following names and meanings and no others will be used formally
to describe our product versions:
Stable: X.Y.Z
the current recommended version for production use
Next-Patch: X.Y.Z++
current version of the next planned patch release of minor
enhancements and defect fixes to the stable X.Y (this might
not actually exist yet)
Next-Minor: X.Y++.0
the current version of the next planned release of new features
which are compatibile with the Major version (this might not
actually exist yet)
Next-Major Z++.0.0
the current version of the next planned release of major
revisions and incompatible changes (this might not actually exist
yet)
+1 to apply this version scheme to James Server
reasons:
This is used in many projects, including James Server and fits my
understanding of versioning very well.
The concrete discussion what is a minor or major or incompatible change
does not go away by pure nomenclature, so I cannot follow Stefanos
reasoning here against it.
I am already annoyed by current reading in line #12 from trunk file
default.properties.
But why are we having a public PMC vote on general@ regarding a James
Server issue? This my vote is only binding for James Server releases.
jSPF for example may establish another versioning scheme.
Bernd
