Aaron Mulder wrote:
We need to update commons-fileupload for 1.1 if it doesn't terribly --
the current one hangs occasionally (when the console processes upload
files) and I'm pretty sure there's a new one available.
There is an update available and has a JIRA for it: GERONIMO-1756 .
Also for your list, I think we need a "What's New in 1.1?" page for
the web site above and beyond the release notes.
As far as the deadlines go, there are a lot of outstanding console
fixes that ought to / need to go into 1.1 (there's a patch for the DB
pools for 1.1 and I think the JMS one needs some attention and there
are a lot of other console JIRAs to review). I'm not sure I'll get it
all together by tomorrow, but we can still make that the "freeze date"
so long as the fixes to existing console functions can continue to go
in.
Finally, I have some thoughts I've put together on my goals/vision for
Geronimo. Should I wait until after 1.1 to get into that discussion?
(I'm not sure that's a good idea; I think we might want to have
something to say along those lines when we're going through the 1.1
release publicity.)
Thanks,
Aaron
On 4/17/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
We're nearing the end of the CTS cycle and will soon have a stable 1.1. Once
we reach this critical
stage we need to move into the final stages to release 1.1. Here is my
proposed list.
*Starting now:*
1. Code freeze for 2006/04/18 23:59 PST (except bug and performance fixes)
*Once we've reached CTS stable:* (feel free to volunteer for tasks)
1. Begin changing packages to upgrade as appropriate (proposed list below)
2. Develop *Release Notes*
3. Draft a *Press Release*
4. Begin performance regression
5. SWAG a date Release Candidate
6. Test, Test, Test
*After 1.1 is stable:*
1. Formalize strategy for syncing 1.1 and HEAD
2. Define a set of release goals for 1.2 and propose a target date
I suggest that we define a theme for a release to help the group focus on a
set of goals
that will guide the work for the next release. This is not intended to be
a rigid
constraint but merely to provide some direction. It will also help us
define a target
release date to help us deliver on a consistent schedule for our users.
3. Solicit user feedback for prioritizing work
Listening to our users and providing them with the features they want.
4. Aggressively update our dependent package versions to new new levels.
Cheers,
Matt
*Version Upgrades - Matt's Suggestions*
I looked at the packages out there and here is the first stab at which ones we
should upgrade.
Comments?
*G* *Available*
*Version* *Package* *Version* *Version*
1.1 activemq 3.2.1 3.2.3
1.1 castor 0.9.5.3 0.9.9.1 or 1.0M3
1.1 daytrader 1.1-SNAPSHOT 1.1-SNAPSHOT
1.1 derby 10.0.2.1 10.1.2.1
1.1 derby 10.1.1.0 10.1.2.1
1.1 jasper 5.5.9 5.5.15
1.1 jasper 5.5.12 5.5.15
1.1 jetty 5.1.9 5.1.10
1.1 openejb 2.1-SNAPSHOT 2.1-SNAPSHOT
1.1 stax 1.1.1-dev 1.1.2
1.1 tomcat 5.5.9 5.5.15
1.1 tomcat_ajp 5.5.9 5.5.15
1.1 tranql 1.2.1 1.3-SNAPSHOT
1.1 tranql_connector 1.1 1.2-SNAPSHOT
