Leo Simons wrote:
Hi all,
Getting our act together
========================
with that pmc vote process just about out of the way (thanks Leo!), infrastructure setup coming along nicely, would it be a good idea to set up a release plan for an across the board avalon release? Do people agree it is worth setting up some rigid structure to be able to get releases out? Are we ready for that?
PMC vote process is done, there is more to do in that area, but it shouldn't keep us from doing a new release.
I started on a release plan, but I kinda found I don't know enough about some excalibur and cornerstone components in order to make any kind of sensible comment there. Is there someone who wants to take on the task of release manager, write up a release plan, schedule, etc? I will try and do it if needed but I feel there's better people for the job.
I have taken on the task in the past. At that time, Excalibur was one big source directory instead of several smaller ones, so it poses a challenge.
Things on our plate
===================
- Phoenix 4.1 (dependendent packages refactored recently, many features that didn't go into 4.0 now making it in IIUC)
- Fortress 1.0 (first release obviously)
- Framework 4.1.4 (javadoc changes, the wrapper classes, some additions to ConfigurationUtil, more tests I believe)
- Logkit 1.1.2 (logfactor 5 additions, other than that I dunno but I do know some features were added)
Yep.
- Cornerstone (this badly needs a release I guess)
It does--even if it is labeled "alpha".
- Lots of excalibur packages (seperated out, bugfixed, new packages etc etc)
Yep.
- AltRMI (I'm guessing it is just about ready for release? Is this baby so big we want to do it seperately?)
There was talk about letting Paul move this to another hosting project. It is something that needs to be done separately.
- Sevak (alpha release, at least? Paul?)
+1
- Demo apps (should we just provide the .sars in the phoenix distribution or release these seperately?)
These should be handled separately. Apps that are working can obviously updated.
Ordered releases
================
Except for AltRMI perhaps (I believe it is really loosely coupled now?), I would think it makes sense that we do a coordinated release of all packages. Perhaps a good order would be:
- Logkit 1.1.2
- Framework 4.1.4
- all excalibur components used in phoenix (ie stuff like baxter)
- Phoenix 4.1
- all excalibur components used in fortress
- Fortress 1.0
- remaining excalibur components 1.0, 1.1, 1.2 releases
- cornerstone components
{- point releases for catching any serious bugs}
- avalon-apps/demo 1.0
- sevak 1.0
{- point releases for catching any serious bugs}
- altrmi 0.9
What we need is to introduce tests for any project that has a dependency to make sure that the contracts that are required do not introduce problems down the dependency tree.
where after each component release, the other projects are updated, branched if neccessary (I think logkit and framework can do with tagging, phoenix is already properly branched), to be compatible with their dependencies. For example, we branch stuff like baxter into a stable branch which compiles against framework 4.1.4, and excalibur-logger into a stable branch which compiles against logkit 1.1.2, etc etc.
All things should be brought up to speed. The most recent releases of each product/project should work if they are used together. If that means we have to release more than one product/project at a time we need to coordinate our efforts. Right now we are experiencing problems with the current release only works with a CVS or an outdated version of a library. Everything has to interroperate.
Status/Schedules
================
What's people's ideas on time schedules? IMO, logkit and framework are ready for release right now, someone just needs to do the work. I haven't done any phoenix testing on the refactoring changes Paul did, but I'm relatively sure it's pretty good to go as well. Paul?
Yep. We need to vote on it.
Fortress itself is nearing the quality needed for a 1.0 release, but I don't know if that is true for all its dependencies. I'm a bit hung up on "remaining excalibur components 1.0, 1.1, 1.2 releases"...Steve, how confident are you wrt your product table accuracy? Can we base decisions of that? Also, how are things going with cornerstone refactoring? Have you got a time schedule for that in mind?
Ok. Fortress dependencies have been simplified. They are now: Jakarta Commons Collections Doug Lea's Concurrency Utils Excalibur Event Excalibur SourceResolve Excalibur Logger Excalibur Container (i.e. the lifecycle extensions) Excalibur Instrument** Excalibur AltRMI That is all that is required. AltRMI is only needed for Instrument, so it is not a hard dependency. Everything other than Instrument and Container has been released. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
