sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Sling > Thoughts on Release Management
Date Mon, 07 Feb 2011 10:16:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2036/9/1/_/styles/combined.css?spaceKey=SLING&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/SLING/Thoughts+on+Release+Management">Thoughts
on Release Management</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~fmeschbe">Felix
Meschberger</a>
    </h4>
        <br/>
                         <h4>Changes (2)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-unchanged" >h1. Thoughts on Release Management
<br> <br></td></tr>
            <tr><td class="diff-changed-lines" >{excerpt:hidden=true}Version Number
and Release Planning <span class="diff-changed-words">Concept<span class="diff-added-chars"style="background-color:
#dfd;"> (IMPLEMENTED)</span>{excerpt}</span> <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >Status: <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">DRAFT</span>
<span class="diff-added-words"style="background-color: #dfd;">IMPLEMENTED</span>
<br></td></tr>
            <tr><td class="diff-unchanged" >Created: 3. January 2008 <br>Author:
fmeschbe <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="ThoughtsonReleaseManagement-ThoughtsonReleaseManagement"></a>Thoughts
on Release Management</h1>



<p>Status: IMPLEMENTED<br/>
Created: 3. January 2008<br/>
Author: fmeschbe</p>


<p>As we should start thinking about making an initial release of Sling, we should discuss
a few issues:</p>

<ol>
	<li>How do number releases ?</li>
	<li>What do we release ?</li>
	<li>When do we release ?</li>
</ol>


<p>In this concept I propose a version numbering scheme as well as my idea for the contents
of an initial Sling release and how to release in the future. Comments are very welcome.</p>


<h2><a name="ThoughtsonReleaseManagement-VersionNumbers"></a>Version Numbers</h2>

<p>Maven has a very nice concept of <em>SNAPSHOT</em> versions. In this
concept, a version just has a <tt>-SNAPSHOT</tt> suffix which marks the version
as a SNAPSHOT (or non-release) version. OSGi versions on the other hand are simply 4-position
numbers, where the parts are separated by dots, first three parts (major, minor, micro) must
be numeric and the last part (qualifier) may also contain characters. The Apache Felix Maven
Bundle Plugin we use to build the Sling bundles converts Maven version numbers to correct
OSGi version numbers. For example, the version <em>2.0.0-incubator-SNAPSHOT</em>
is converted to <em>2.0.0.incubator-SNAPSHOT</em>.</p>

<p>The consequence of this conversion is that a SNAPSHOT version (e.g. <em>2.0.0.incubator-SNAPSHOT</em>)
would always be assumed more recent than the corresponding release version (<em>2.0.0.incubator</em>
in this example). Instead of just do hackery with the release version, such as adding a different
suffix, I propose the following version numbering concept:</p>

<ol>
	<li>Odd micro versions are always SNAPSHOTs, e.g. <em>2.0.1-SNAPSHOT</em></li>
	<li>Even micro versions are always releases, e.g. <em>2.0.2</em></li>
</ol>


<p>This way, a release is always more recent than the latest SNAPSHOT from which the
release was built. This also means, that there is never an official release with an even micro
version and there will never be an "official" SNAPSHOT with an even micro version. Thus both
<em>2.0.2-SNAPSHOT</em> and <em>2.0.3</em> would be incorrect version
numbers.</p>

<p>So, when releasing project, the minor version of the release is the next increment
to the current SNAPSHOT micro version. The new SNAPSHOT micro version is again the next increment
of the release version. For example to release the current SNAPSHOT <em>2.0.3-SNAPSHOT</em>,
the following version numbers are used:</p>

<ul>
	<li>Current SNAPSHOT version: <em>2.0.3-SNAPSHOT</em></li>
	<li>Release version: <em>2.0.4</em></li>
	<li>Next SNAPSHOT version: <em>2.0.5-SNAPSHOT</em></li>
</ul>



<p>The same mechanism applies when we decide to increment the minor or even the major
version number: Up to the release, the SNAPSHOT remains with the former minor (or major) version
and only on release, are the version numbers incremented. For example to release the current
SNAPSHOT <em>2.0.7-SNAPSHOT</em> as <em>2.1.0</em>, the following
numbering is used:</p>

<ul>
	<li>Current SNAPSHOT version: <em>2.0.7-SNAPSHOT</em></li>
	<li>Release version: <em>2.1.0</em></li>
	<li>Next SNAPSHOT version: <em>2.1.1-SNAPSHOT</em></li>
</ul>



<p>For branching, the branch always gets an incremented minor version number. For example
when branching off <em>2.1.1-SNAPSHOT</em> the branch version would be <em>2.2.1-SNAPSHOT</em>.
The problem then is: What would be the next minor version if <em>2.1.1-SNAPSHOT</em>
would be released with an incremented minor version ? One solution could be to not only define
the branch version number but to also increment the trunk minor version to the next minor
version. In the example, this would raise the trunk version number to <em>2.3.1-SNAPSHOT</em>
(from <em>2.1.1-SNAPSHOT</em>). Alternatively, we may just append a suffix indicating
the branch, such as <em>2.1.1.branch-SNAPSHOT</em>.</p>

<p>Both solutions actually have their drawbacks and maybe we never even need this, because
I cannot imagine requiring a branch. The reason for this assumption is, that we release "small"
bundles, which may easily and quickly be fixed and fix release be provided equally quickly.</p>


<h2><a name="ThoughtsonReleaseManagement-ReleasesofSling"></a>Releases of
Sling</h2>

<p>For a starter we will have an initial release of Sling. This release will most probably
encompass the following constituents:</p>

<ul>
	<li>A standalone Java Application consisting of a single JAR file (or a ZIP) containing
all bundles used by Sling</li>
	<li>A web application (WAR file) containing all bundles used by Sling</li>
	<li>All bundles packed into the standalone and web applications</li>
	<li>The parent POM</li>
</ul>


<p>After the initial release, further releases will only be made of single bundle (or
a small number of bundles). Whenever we see a release fit, we will cut it. Some bundles will
have longer and some bundles will have shorter release cycles. This all depends on the importance
of the fixes and/or the enhancements applied as well as the needs by the user community.</p>


<h3><a name="ThoughtsonReleaseManagement-PackagedBundleReleases"></a>Packaged
Bundle Releases</h3>

<p>For end users and beginners it is very helpfull to have completely package Sling
application (or web application) in their hands to try it out and start build web applications.
In addition, such prepackaging also serves well for prototype building and "just testing it".</p>

<p>For this reason, there will be packaged releases of the standalone and web application
once or twice a year. These applications though would just be packagings of already released
bundles.</p>


<h2><a name="ThoughtsonReleaseManagement-ReferringtootherSlingProjects"></a>Referring
to other Sling Projects</h2>

<p>Most Sling projects depend on other Sling projects. After the initial release all
Sling projects should only refer to other Sling projects by their release number. Only, if
a projects uses non-released functionality of another project, should the SNAPSHOT version
be referred to.</p>

<p>Also, the release of a Sling project will not cause the dependencies of Sling projects
using the released project to be incremented. That is, each Sling project always refers to
the smallest possible version number of other Sling projects.</p>

<p>This helps managing the dependency tree and prevents needless upgrades of bundles
in running systems.</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/SLING/Thoughts+on+Release+Management">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=73751&revisedVersion=5&originalVersion=4">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/SLING/Thoughts+on+Release+Management?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message