axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Butek <bu...@us.ibm.com>
Subject Re: Rationale for shipping v1.0 - ALL COMMITTERS PLEASE READ!
Date Sun, 08 Sep 2002 19:03:11 GMT




+1.

So who's the release manager for 1.0?  Tom did 1.0 RC, but if I remember,
he's gone this week.  So is Glen.  And Rich and I have gotten dragged into
other tasks and don't have the time this week.

Russell Butek
butek@us.ibm.com


Sam Ruby <rubys@apache.org> on 09/06/2002 05:51:24 PM

Please respond to axis-dev@xml.apache.org

To:    axis-dev@xml.apache.org
cc:
Subject:    Re: Rationale for shipping v1.0 - ALL COMMITTERS PLEASE READ!



Tom Jordahl wrote:
 > In the interest of keeping things simple, I would like to NOT do any
 > branching of the source tree unless there is a major reason for it.
 > For instance, if after we release 1.0 and probably at least 1 or 2
 > updates, we might want to make a 2.0 branch for work that is deemed
 > too destabilizing for the mainline 1.x branch.
 >
 > At least this is how I think it should be done, other may think
 > differently. :-)

I most *DEFINATELY* want a branch at 1.0 time, but the one I would like
to see is different than most people will presume, so give me a moment
and hear me out.

As a purely hypotetical example, if in the process of creating a 1.1, I
do further work on SOAP 1.2 or Glen rewrites deserialization and then
somebody finds a need for an emergency "hot fix" on 1.0 (a security
hole, for example), I don't want to be in a position where we have to
force what will amount to a nightly build onto the world.

So, what I would like to see, preferably shortly before 1.0 ships, a 1.0
branch.  That branch would contain exactly what is shipped with on 1.0
and whatever immediate fixes are deemed necessary.

This will have virtually no impact on anybody.  People will continue to
commit to the main branch as normal.  The only time somebody will have
to do something special is when a fix is required.

Ideally, this would be done shortly before the release, as that will
allow the release manager some assurance that what he is builing isn't
changing.  But I will leave that up to the release manager to decide.

Make sense?

- Sam Ruby




Mime
View raw message