james-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: [VOTE] Release descriptions
Date Thu, 16 Nov 2006 20:48:53 GMT
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

Mime
View raw message