incubator-hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alois Cochard <alois.coch...@gmail.com>
Subject Re: Versioning
Date Fri, 15 Apr 2011 11:34:18 GMT
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 are
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’s 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 “nonrisky” 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
>



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message