I originally said I would release a new candidate after 1400 eastern time today. Truth is I'm
pretty wiped out and would like to cut a release tomorrow (Saturday). We'll add some additional
time for JSisson as he is clearly doing something other than working :)
I propose that the next candidate is released on Sunday and allows 72 hours for feedback. Is
everyone ok with that ?
Aaron Mulder wrote:
So as I understand this, the plan is:
- new release candidate today, no more non-critical patches
- begin voting for that release candidate today
- if critical bugs are found within 72 hours, someone will -1 the
vote, we will fix and cut a new release candidate, and start a new
72-hour vote
I'm OK with that for this release (I don't think it's ideal, but I
agree that it will be nice to get this release out the door, so I'm on
board). I hope someone will look at the weird web services error
during deployment, because I don't know what to make of that (if it's
reproduceable and how significant it is).
If I'm right about the release plan, I think we should create a SVN
home for 1.1.1-SNAPSHOT now so there's a place to put non-critical
patches. It will be annoying to put critical patches into 3 places,
but we're hoping there aren't any of those.
Thanks,
Aaron
On 6/8/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
Final Items for 1.1
I would like to release Geronimo 1.1 on June 12th. Yes, that is three
days away. If we can't make
that date then it will be 72 hours away from each candidate build.
Problem that are found need to
be addressed if they are deemed critical. Otherwise they will be
tracked and solved in a follow on
release.
That said. I sent a note earlier today announcing the freeze to
branches/1.1. Changes to this
branch should be limited to bug fixes only. The little changes are
the ones that generally burn
you. At 1400 ET the Inn is closed and I will spin up a release that
will be our release candidate.
The issues that have been raised from the previous build were
Guillaume's observation of the problem
when running Geronimo under CygWin as well as the license and Notice
issues.
Since Geronimo is a multifaceted project there are several things that
need to be voted on. They
are Geronimo itself, the specification jars and DayTrader. Geronimo
itself is the significant
component that will carry the other items so I believe a vote for
Geronimo in this context is a vote
for all three items.
*There is a concern about the specification jars*
David Jencks raised this issue in another note on the list. The jars
have not been released but
they have had a tag cut and the resulting compilation has been placed on
http://people.apache.org/repository.
One of the issues I found with the spec is that there are different
spec releases in the 1_1 tag. I
would prefer that all jars have the same version suffix. Right now it
includes 1.0, 1.0.1, 1.1 and
others. I think this is confusing. We release Geronimo with all the
same module versions even if
nothing has changed. I would like to move that we recut a 1_2 tag
with all spec jars having a 1.2
suffix.
*DayTrader*
Day Trader is currently a 1.1-SNAPSHOT as well. We will release the
DayTrader Ear (separate from
Geronimo) as a 1.1 version as well. This way the build will be in sync.
*Issues*
1. It was noted earlier today that there is a problem with Geronimo
under CygWin. Guillaume noted
that an issue exists where a file is not renamed (config.xml). Given
that CygWin is a hybrid
environment I think we should investigate this problem but not hold up
the release.
2. Guillaume also pointed out the lack of a License and Notices file.
I will include the two files
from the SVN geronimo/branches/1.1 in the build tomorrow.
3. Numerous bug fixes are being addressed. Excellent.
Apart from Spec issue above I think we have most everything
addressed. Does this list of
outstanding items and release plan make sense?
Matt
