james-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [VOTE] Release descriptions
Date Thu, 09 Nov 2006 11:07:36 GMT
-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.



Mime
View raw message