Mailing-List: contact hama-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hama-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of alois.cochard@gmail.com
 designates 209.85.212.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=lg5mr6plYEU9cMYzSjqNKg0FuNZWkhmSoWgVXMreafRgRQNzwbyT3blmJWnXTiDMGY
         BCNJXt1v8uolNLzIup3KJBzxxiOCkukXyVbyd7pR1EomvtoVY7d776yTQTKuDc2JxRVF
         FnRSnOBHEglEW6I++3GXaehvZAzYiB8Q1+xcA=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=-_oNQgx3kbxSMTK+o=znSuFofMg@mail.gmail.com>
References: <BANLkTi=-_oNQgx3kbxSMTK+o=znSuFofMg@mail.gmail.com>
Date: Fri, 15 Apr 2011 13:34:18 +0200
Message-ID: <BANLkTikWtQOHRWZ3HH2y=NyGpoG7HW6LUw@mail.gmail.com>
Subject: Re: Versioning
From: Alois Cochard <alois.cochard@gmail.com>
To: hama-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec548a2e926d6ef04a0f36cfe

--bcaec548a2e926d6ef04a0f36cfe
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello all,

Looks like a good versioning strategy for me,

I'm just skeptic about how this will be understood by the user, and what ar=
e
the real advantages between this and a traditional versioning strategy ?

The first advantage I see: It's prevent to increment major version too much
if we have small development iteration - having version 20.1 in 2 years for
example ;)

But in case of long time iteration I don't see the advantage, what are the
planned release cycle ?

I don't see any date on the roadmap:
http://wiki.apache.org/hama/RoadMap

Thanks !


On 15 April 2011 04:28, Edward J. Yoon <edwardyoon@apache.org> wrote:

> Maybe this is what we should do ..
>
> ----
> MongoDB uses a fairly simple versioning scheme: even-point releases
> are stable, and odd-point releases are development versions. For
> example, anything starting with 1.6 is a stable release, such as
> 1.6.0, 1.6.1, and 1.6.15. Anything starting with 1.7 is a development
> release, such as 1.7.0, 1.7.2, or 1.7.10. Let=92s take the 1.6/1.7
> release as a sample case to demonstrate how the versioning timeline
> works:
>
> 1. Developers release 1.6.0. This is a major release and will have an
> extensive changelog. Everyone in production is advised to upgrade as
> soon as possible.
>
> 2. After the developers start working on the milestones for 1.8, they
> release 1.7.0. This is the new development branch that is fairly
> similar to 1.6.0, but probably with an extra feature or two and maybe
> some bugs.
>
> 3. As the developers continue to add features, they will release
> 1.7.1, 1.7.2, and so on.
>
> 4. Any bug fixes or =93nonrisky=94 features will be backported to the 1.6
> branch, and 1.6.1, 1.6.2, and so on, will be released. Developers are
> conservative about what is backported; few new features are ever added
> to a stable release. Generally, only bug fixes are ported.
>
> 5. After all of the major milestones have been reached for 1.8.0,
> developers will release something like, say, 1.7.5.
>
> 6. After extensive testing of 1.7.5, usually there are a couple minor
> bugs that need to be fixed. Developers fix these bugs and release
> 1.7.6.
>
> 7. Developers repeat step 6 until no new bugs are apparent, and then
> 1.7.6 (or whatever the latest release ended up being) is renamed
> 1.8.0. That is, the last development release in a series becomes the
> new stable release.
>
> 8. Start over from step 1, incrementing all versions by .2.
>
> --
> Best Regards, Edward J. Yoon
> http://blog.udanax.org
> http://twitter.com/eddieyoon
>


--=20
*Alois Cochard*
http://aloiscochard.blogspot.com
http://twitter.com/aloiscochard

--bcaec548a2e926d6ef04a0f36cfe--