-1
For people bored by my long explanations: generally speaking I agree on
the concepts but I'm against details (and missing details) and the fact
that it *now* create even more confusion between current labels and the
release scheme.
Stefano
And here the long one:
----------------
Generally speaking I agree and I think this is the most use scheme out
there, but the problem is always in details.
I will cast my vote later, but I think I will vote against a so general
description, because it give us the impression to have agreed something
while we didn't.
X - the description contain a "major changes" reference: what is a major
change? A refactoring of a component that keep functionality? A complete
new feature? A big performance enhancement? A change in the container?
An update of the javamail library? Without a clear definition of "major
changes" is hard to agree/disagree.
Y - new backward compatible features: we have to define the scope of
backward compatibility, otherwise it is meaningless (e.g: for current
"next-minor" and "next-major" we're speaking of "config.xml and storage
compatibility". This is one kind of backward compatibility and is much
more strict than the compatibility between 2.1 and 2.2 and the
compatibility between 2.2 and 2.3 (we had only storage compatibility in
that "upgrades"). Another "detail" is that we never had binary API
compatibility between versions. Backward-compatibility is a big issue,
so while I think we all agree that Y change means backward-compatible,
I'm also sure we have different ideas on backward-compatibility details.
Z - Imho it should not generally contain enhancements, only bug fixes.
Otherwise we again have to define what is a "minor enhancements to
existing feature".
To be clear "next-minor" and "next-major" labels has been used as
labels, and they are not related to what you define Next-Major and
Next-Minor in this context.
As an example following your proposed scheme I don't know if what we
labelled "next-minor" should be numbered 2.3.1 or 2.4.0 (minor
enhancement, backward compatibility) and I don't know if "next-major"
should be numbered 2.4.0, 2.5.0 or 3.0.0 (is backward compatible so 2.x
apply, but we'll probably have different opinions about the "importance"
of the changes).
The difference between what we are labelling "next-minor" and
"next-major" is that next-minor will contain a subset of backported
features from next-major. Both are backward compatible and the rule for
the backport has not been defined as "minor changes" but as "vetted
code". So I think both releases belong to the same "X" but different "Y".
I think I will be +1 to name "next-minor" 2.4.0 and "next-major" 2.5.0,
but I want to know something more about next-minor before casting my
vote about it.
I would leave the 3.0.0 for the release that will include repository
refactorings, non backward compatible config, next generation mailet
api, and maybe java2 5.0 annotation support.
Stefano
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)
d.
