Hi folks, Jukka wrote: > The main problem I see with going with component releases is that > using Jira for release management becomes a bit tricky. So far the > "Fix version" tags in Jira have been one of my key tools in tracking > which issues go into which release. To solve that we could either > split JCR into multiple separate Jira projects, or use the component > tags to scope the release numbers.
You'll have to use separate JIRA projects. Versions are not scoped per component, and you can only change between "unreleased", "released", and "archived" on the version level. Infra is aware of this and grants you a JIRA project for each separately releasable package [1]. As an added bonus, you'll see in the subject of the JIRA mails to which JIRA project they belong. > Either way we'll end up with problems if we have an issue that > affects more than one component at a time. You'll create separate issues and link them. Either as subtasks, or "depends on" or "blocks". Plenty of options there. However, I strongly suggest that you don't put 22 artifacts on separate release cycles. Every release comes with some overhead in preparing release notes, reviewing the artifacts, voting on the release, performing the release, sending the release mail, and updating the web page. That may not seem much while you're dealing with one release for all artifacts, but if you multiply that overhead twentyfold, you'll feel the pain. It will also get you and your users into dependency hell. Felix should be able to tell you a story or two about that from Apache Felix. IIRC, the next release of the maven-bundle-plugin depends on several other releases that have to be done first. I recommend to shoot for a manageable 5 or 6 independent release cycles. Without knowing the internals of Jackrabbit, for example: - base/common/util classes used almost everywhere - repository API and SPI - repository implementation(s) - remoting - WebDAV - ? I hope you get the idea. I know that the WebDAV component itself has a base, client and server section. Likewise, the remoting stuff surely has a client and a server section. But releasing one without the other is not likely, right? Splitting the code into components and packaging it into separate JARs is still possible if they are on the same release cycle. That's what JIRA components are good for. cheers, Roland [1] http://www.apache.org/dev/project-creation-tasks.html
