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