+1 for option 2, it seems the quickest one.
I just put the "News" out, it takes some time to get propagated.
Cheers!
Hernan
Matt Hogstrom wrote:
All,
Earlier today one of the Geronimo committers discovered a bug in the
command line deployer where a null user / password on the deployer
command line will allow a user to deploy modules to a 2.0 server. This
is an unacceptable security exposure and as such we have abandoned the
release of Geronimo 2.0.
Donald Woods is going to open a JIRA for this issue and Hernan will
create a news item on our web page.
At this point we need to discuss how to move forward with a 2.0 release.
I think we should delete the tags/2.0.0 entry and replace it with a text
file that notes the svn rev of the tree before deletion. The purpose of
this is to avoid anyone from picking up that source tree and using it to
build a server with a known security exposure. Unless there is
disagreement I'd like to do that tomorrow allowing some time for
discussion. We can always put it back.
There are several options for the 2.0 release:
1. Use the branches/2.0 to spin up a new release as 2.0.1.
If we do this there are a number of fixes that need to be verified,
We'd need to close out the SNAPSHOT releases again, or at least revisit
them.
Respin and re-tck a new release.
2. Take the tags/2.0.0 to create a branches/2.0.1
This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT
Copy the existing tag over and apply the security fixes. Repsin and
release.
Personally, I vote for option 2. Based on my experience, closing out
the SNAPSHOTs is and introducing little changes will cause us to restart
the release process.
I'd like to hear other people's input but having done the release
several times option 2 is the fastest. I think option 1 will cause us
to not release until September.