I know it is tedious for smaller broken out project JIRAs to be in sync with the code/releases, especially when the initial Betas are still in progress (e.g. http://jira.jboss.com/jira/browse/JBVFS) *but* when this stuff reaches a state that will need to be supported, it will be very hard to track what went into a release, unless we maintain some discipline, i.e. the obvious stuff: don't commit without a linked JIRA task and properly mark versions as released. Something else to avoid is using "foreign" JIRA tags in commit message. E.g like JBCTS / JBWS / JBPAPP / ... tags in community AS branches/trunk, rather use JBAS tag that link back to the other projects. Finally, the more projects are broken out into smaller ones (with their own JIRA, etc) the more difficult it becomes to assemble meaningful release notes, and many users have complained about that. My proposal would be that for every updated component (or set of components if they are tracked together): 1) there should be a JIRA task to track the upgrade, e.g. when upgrading the jbosssx libs. 2) this JIRA should either embed or link to the release notes of the upgraded component 3) the task should be re-used if upgrading multiple times within the same target release 4) the rule would apply for both jboss and thirdparty libraries This is something I'm trying to enforce for upgrades I'm doing myself, but it would be great to have a wider consensus / application of this practice. I would also like to propose that we introduce a new JIRA type next to 'feature', 'bug', etc. called e.g. 'Component Upgrade' to mark those JIRA tasks. By doing so, the component upgrades: - would immediately stand out in the release notes report - the user will be able to drill-into the jira task and find out exactly what the upgrade is about. That would be quite simple and effective, I think. Thoughts? /Dimitris -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Dimitris Andreadis JBoss AS, Project Lead JBoss, a Division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx