On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote: > Bottom line, the fewer subprojects and even "modules", the quicker a GA > release will happen and the easier the project will be to manage.
Having done the release both ways, I don't see that multiple JARs is a problem. The work of creating a release is managing the plan, ensuring that all the relevent issues are resolved, checking the dependencies, and testing the code. Running the builds is mechanical and easy to automate. It's not uncommon for a project our size to distribute multiple JARs. Spring is probably the best example. The question is whether the version numbers of the JARs move together or move in synch. For the 1.3.0 build, we kept the JARs in synch, so that we would have a common baseline. Of course, because we had so much code to release at once, it took just as long as all the other releases. We were ready to go once before, back in November, but we held up all the code in all the JARs for another four months because of one dependency used by one new feature in the "Extras" JAR. Same old. Same old. One wrinkle, and none of the wallpaper goes up. I can't step up to the plate on the quality vote for the 1.3.0 builds myself. If someone else is interested, I'd suggest calling for a vote on 1.3.0, and we will see what happens. Then, when someone is ready to do a 1.3.1 build, we can decide whether to continue keeping all the "classic" JARs together, or whether we want to start tagging the JARs separately. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
