In earlier emails I have posted details of the technical things I wanted to clean up before a release - all of these items are now complete.
things really have improved across the board since I last checked...
I particularly like the way the tutorials are shaping up. Some language still very complex in places ("An appliance can be view as an instance of a unique named deployment scenario where a deployment scenario is the result of combining a particular component type with deployment meta-data"), but general usage patterns really are getting clear.
Some of the actions I think should be taken before a release include the following:
1. additional tutorials covering: - custom contextualization - dynamic components 2. complete the documentation about the James example 3. add documentation concerning the Merlin/Maven plugin
I think complete docs are never a requirement or showstopper for any 1.0 release. I think merlin docs overall are in rather good shape.
3. resolve a manifest generation problem that is currently
preventing the proper management of extensions
4. either release Excalibur Extension or include a fork
under the Merlin project
for the moment, the latter may be the least headache; it's only a few classes after all. Just mark them as for internal use only :D
5. make sure everything is in sync with the recent
Excalibur releases
what I would like as a basic validation test is an example built using the 1.0 fortress release running inside a merlin appliance, with all shared jars between merlin and fortress actually shared. Should be a nice test. thoughts? How feasible would that be?
6. tag the CVS
the forrest peeps have a real nice doc about release preperation @ http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/etc/RELEASE_PROCESS.txt?rev=HEAD&content-type=text/plain
which you might want to review :D
7. vote on a release
what worries me a little here: who knows enough to vote? The PMC handles votes on avalon releases, yet the only person who has made significant commits (or patches) to Merlin is you. I've done some trivial cleanup, as have Berin and PeterD, and many people have given feedback or provided some minor patches, but most of the extensive merlin codebase is known well only to you.
This sort-of conflicts with the desire to be able to guarantee continuity of any ASF release by having a sizeable developer pool. I guess merlin is, at the moment, "in incubation" here @ avalon, waiting for that developer pool to arrive. Until that happens, I think it should be clear to potential users and developers that merlin does not have such a developer pool.
Building and making available a release sort-of sends the opposite signal. The message to people asking for a release is then to be something like "well, we want more developers to get to grips on the code before we do that; feel free to join in". If things are as snappy as you say, you are certainly not going to be able to handle all "support questions" on your own.
Dunno. I guess one way to accomodate these concerns would be to release the files with a '-dev' or '-beta' postfix.
thoughts?
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
