axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: [Axis2] Release Strategy
Date Fri, 30 Sep 2005 12:53:01 GMT
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.

Good point. Labelling something alpha implies "unstable, alpha-quality 
and of transitive duration", where alphas often last a few weeks,

a 0.92 release says "not 1.0 yet, but ready to use with caveats"

> 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.

Certainly its nice to have 0 changes between final beta and release,.

> 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.

I think a few of us got our PGP keys done there.

I actually have to use JAR files in a secure (signed) env. It'd be good 
for a build process if we integrated signing, just to catch any problems 
(usually related to other JARs duplicating things, the way xbeans does 
with javax.qname).

That does not mean that we should release signed JARs onto the maven 
repository, because when the java classloader sees a signed jar, it 
immediately flips into semi-secure mode, not loading any classes into 
the same packages unless signed by the same person. Its just nice to be 
know that we can get everything to work in signed mode if desired, such 
as in a JNLP-downloaded app.


View raw message