axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [Axis2] Release Strategy
Date Fri, 30 Sep 2005 14:24:04 GMT
Key phrase is ------>>>>>>>>  "until Axis2 is feature complete". Eran
keeps asking for feedback and don't get any :(

Could you please help put together the features list? Get OK's from everyone?


On 9/30/05, robert burrell donkin <> wrote:
> I'd glad that the team decided to release the last cut as 0.9.2 rather than
> 1.0 Alpha and I'd like to explain my reasons in a little more depth (now
> that the release is cut). I think everyone appreciates the efforts that have
> been put into get this far.
>  IMHO Axis2 0.9.2 is a more appropriate description of where the Axis2
> project is at the moment than 1.0 Alpha. What's there is reasonably solid
> but (as a whole) is feature incomplete. 0.x releases have a long and proud
> history. For example, openssl is only on 0.9.8.
>  Alpha's (on the other hand) are transitory. It is not unreasonable to
> expect that an Alpha will be replaced with a Beta similar (in functionality
> to the Alpha) but with bugs fixed and more proven stability. Working out the
> order of Alpha's and Beta releases is also less obvious (for example, it is
> no uncommon to see Alpha1, Beta1, Beta2, Alpha2, Beta3, RC1 as bugs are
> uncovered in the system). This makes tracking feature additions to Alpha's
> and Beta's a PITA. Much better to use 0.x versions when it is know that
> there is functionality that will be added.
>  So, I recommend continuing to cut regular releases in the 0.9.x series
> until Axis2 is feature complete (for the 1.0 release). IMHO this is likely
> to create more momentum than a series of Alpha's especially if the releases
> are frequent.
>  This seems like a good time to offer up some information about a way of
> doing release management which has been adopted by many of the large and
> popular projects here at Apache including HTTPD, Structs and Tomcat. The
> basic idea is that it is the same code which progresses from RC to Alpha to
> Beta to Full release as it is tested and verified. If at any stage issues
> are found which prevent it progressing, the process starts from scratch.
> This gives a longer release cycle but ensures a higher quality final
> release. It also creates momentum.
>  Another HTTPD innovation (which I really like) I heard about at ApacheConEU
> was movement towards all approving committers signing the release (indeed:
> signing the release is the accepted form of +1). This not only improves
> security (attackers need to compromise every key it's signed with) but IMHO
> leads to a real sense that it's a team release.
>  Robert

Davanum Srinivas : - Oxygenating The Web Service Platform

View raw message