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