directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Directory Project Management > Version Numbering Scheme
Date Tue, 11 Jan 2011 17:08:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/1810/9/1/_/styles/combined.css?spaceKey=DIRxPMGT&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/DIRxPMGT/Version+Numbering+Scheme">Version
Numbering Scheme</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~elecharny">Emmanuel
L├ęcharny</a>
    </h4>
        <br/>
                         <h4>Changes (27)</h4>
                                 
    
<div id="page-diffs">
            <table class="diff" cellpadding="0" cellspacing="0">
            <tr><td class="diff-unchanged" >h2. Introduction <br> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">A
3 point numbering scheme is used for versioning: <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">A
3 point plus a date numbering scheme is used for version. We follow the Eclipse scheme : <br></td></tr>
            <tr><td class="diff-unchanged" > <br>{noformat} <br></td></tr>
            <tr><td class="diff-changed-lines" ><span class="diff-changed-words">[directory:major].[directory:minor].[directory:micro]<span
class="diff-added-chars"style="background-color: #dfd;">-[vYYYYMMDD]</span></span>
<br></td></tr>
            <tr><td class="diff-unchanged" >{noformat} <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >A change to discontinue support for
a specific platform may also trigger a bump in the major version number.   <br> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">{note}
<br>Some consider bumping the minor number several notches from say a 1.0 to a 1.5 for
example to connotate a change in platform like switching from JDK 1.4 to JDK 5.0.  This is
also an acceptable tactic to employ.  <br>{note} <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h2. Minor Number <br> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Minor
numbers are used to connotate changes to features and APIs in the product with minor changes
which may or may not introduce compatibility issues.  The compatibility issues are not severe
ones where dependent applications must completely rewrite junctions using/integrating the
product. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Minor
numbers are used when new features and APIs are added in the product. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Furthermore
odd minor numbers connotate unstable developmental releases to introduce new features to the
community.  Even numbered minor numbers are for stable product releases which are recommended
for use in production.   <br> <br></td></tr>
            <tr><td class="diff-unchanged" >Minor numbers usually correspond to
separate branches of development on the same code base. <br> <br>h2. Micro Number
<br> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">If
the minor number is odd, the micro number represents new feature additions in a development
release from a feature branch.  Bugs may be fixed from previous releases or they may not with
only simple feature introductions.  There is no quality assurance taking place here.  Only
new features are being introduced with the chance that bug fixes are also occuring. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Micro
numbers are used for bug fixes. No new features, no API change. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">If
the minor number is even, the micro number represents *ONLY* bug fixes in a production release
of a stable branch.  No new features are being added and absolutely no API changes are being
made.  The only thing other than bug fixes which can go into these micro releases of stable
branches are performance optimizations. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h2.
Date <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2.
Using Release Candidate (RC) Designators  <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">The
added date (prefixed by the letter &#39;v&#39;) is used for intermediary builds. They
are used for people who need a version to test some fix, before the official release is out.
<br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">At
some point developers will decide to freeze the introduction of new features and focus on
stabilizing the software.  At such a point in time a new stable branch may be created with
an even version number.  For example in a 1.3 branch developers might decide it&#39;s
time to freeze features and start stabilizing the product for a 1.4 release. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h2.
Using Milestones (Mx) designators <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">At
these boundries between a development branch (odd minor number) and a stable branch (even
minor number) developers might not want to immediately release 1.4 without making some release
candidates available to the public to test.  Here the RC designator can be used to tell users
that this is a feature frozen release for testing and not a true production grade release.
<br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Milestones
are used when working on a major release. They don&#39;t promise anything to the user,
even in term of API stability. The idea is to offer some visibility on the upcoming version,
instead of working in a 2 years tunnel.  <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">All
successive RCs will try to irradicate known bugs in the software.  Once a RC is deemed stable
the production ready release can be made using an even minor number (1.4.0 in the example
above).  Between RC releases only bug fixes or optimizations should be made without changes
to the API.  You&#39;re trying to stabilize the software for production and don&#39;t
want to make changes that may destabilize the product or change the expectation of users.
 In this stage users can start using the product with a guarantee that interfaces will not
change but glitches will be fixed so they can incorporate the product into their beta offerings.
<br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Again,
we do *not* guarantee API stability between two milestones ! <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2.
Handling Unusual Circumstances  <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h2.
Using Release Candidate (RC) designators  <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Sometimes
big changes in architecture or a complete rewrite bump up the major version number.  If immediately
after these changes the community wishes to feature freeze development and come out with a
new major version number then they can stablize the release using release candidates of the
new major version with minor number 0. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Release
candidate are for major or minor release only, not for micro releases, as they are just bug
fixes). <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">At
other times major number bumps may be required but the community still plans on adding new
features in subsequent releases so the new major revision with minor number of 0 cannot connotate
a stable release.   <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">At
some point developers will decide to freeze the introduction of new features and focus on
stabilizing the software, after havng gone through a set of milestones. The RC designator
can be used to tell users that this is a feature frozen release for testing and not a true
production grade release. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">In
these cases the change in the major number can also jump to an odd minor number.  Say ApacheDS
is rewritten entirely at some point when it&#39;s highest released version at 5.6.4. 
The newly released technology preview may be released as a 6.1.0 to denote it&#39;s instability
and the fact that more features will continue to be added.   <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">All
successive RCs will try to eradicate known bugs in the software.  Once a RC is deemed stable
the production ready release can be made (1.4.0 for instance).  Between RC releases only bug
fixes or optimizations should be made without changes to the API.  You&#39;re trying to
stabilize the software for production and don&#39;t want to make changes that may destabilize
the product or change the expectation of users.  In this stage users can start using the product
with a guarantee that interfaces will not change but glitches will be fixed so they can incorporate
the product into their beta offerings. <br> <br>h2. Handling Unusual Circumstances
 <br> <br>Sometimes big changes in architecture or a complete rewrite bump up
the major version number.  If immediately after these changes the community wishes to feature
freeze development and come out with a new major version number then they can stabilize the
release using release candidates of the new major version with minor number 0. <br></td></tr>
        </table>
</div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h2><a name="VersionNumberingScheme-Introduction"></a>Introduction</h2>

<p>A 3 point plus a date numbering scheme is used for version. We follow the Eclipse
scheme :</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>  [directory:major].[directory:minor].[directory:micro]-[vYYYYMMDD]
</pre>
</div></div>

<h2><a name="VersionNumberingScheme-MajorNumber"></a>Major Number</h2>

<p>The major number represents significant differences between software releases.  Changes
in the major version represent incompatible changes in architecture, platform or API.  A complete
rewrite or redesign may bump the major version number.  </p>

<p>A change to discontinue support for a specific platform may also trigger a bump in
the major version number.  </p>

<h2><a name="VersionNumberingScheme-MinorNumber"></a>Minor Number</h2>

<p>Minor numbers are used when new features and APIs are added in the product.</p>

<p>Minor numbers usually correspond to separate branches of development on the same
code base.</p>

<h2><a name="VersionNumberingScheme-MicroNumber"></a>Micro Number</h2>

<p>Micro numbers are used for bug fixes. No new features, no API change.</p>

<h2><a name="VersionNumberingScheme-Date"></a>Date</h2>

<p>The added date (prefixed by the letter 'v') is used for intermediary builds. They
are used for people who need a version to test some fix, before the official release is out.</p>

<h2><a name="VersionNumberingScheme-UsingMilestones%28Mx%29designators"></a>Using
Milestones (Mx) designators</h2>

<p>Milestones are used when working on a major release. They don't promise anything
to the user, even in term of API stability. The idea is to offer some visibility on the upcoming
version, instead of working in a 2 years tunnel. </p>

<p>Again, we do <b>not</b> guarantee API stability between two milestones
!</p>

<h2><a name="VersionNumberingScheme-UsingReleaseCandidate%28RC%29designators"></a>Using
Release Candidate (RC) designators </h2>

<p>Release candidate are for major or minor release only, not for micro releases, as
they are just bug fixes).</p>

<p>At some point developers will decide to freeze the introduction of new features and
focus on stabilizing the software, after havng gone through a set of milestones. The RC designator
can be used to tell users that this is a feature frozen release for testing and not a true
production grade release.</p>

<p>All successive RCs will try to eradicate known bugs in the software.  Once a RC is
deemed stable the production ready release can be made (1.4.0 for instance).  Between RC releases
only bug fixes or optimizations should be made without changes to the API.  You're trying
to stabilize the software for production and don't want to make changes that may destabilize
the product or change the expectation of users.  In this stage users can start using the product
with a guarantee that interfaces will not change but glitches will be fixed so they can incorporate
the product into their beta offerings.</p>

<h2><a name="VersionNumberingScheme-HandlingUnusualCircumstances"></a>Handling
Unusual Circumstances </h2>

<p>Sometimes big changes in architecture or a complete rewrite bump up the major version
number.  If immediately after these changes the community wishes to feature freeze development
and come out with a new major version number then they can stabilize the release using release
candidates of the new major version with minor number 0.</p>

    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/DIRxPMGT/Version+Numbering+Scheme">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=28597&revisedVersion=9&originalVersion=8">View
Changes</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message