L.S.,
Looks like we agree to put things in a single JIRA project for all the
components for now. Personally, I would prefer to use the plain version
numbers, because we'd otherwise end up with another endless list of
releases (servicemix-ftp-2008.01, servicemix-jms-2008.01, ....) in the
new JIRA project. The only drawback I see is that we'd also have to
create shared filters to get some kind of roadmap per component. Is
there any obvious problem with using plain versions that I'm missing?
+1 on Chris' suggestion to add better release information for the
components to the wiki as well, that will also help in getting the
release information for the containers out -- we could just point to the
release notes of the components we include instead of having to
aggregate the data from both JIRA projects.
I'll try to migrate things over the weekend once we get a consensus on
the versioning scheme. I guess we best move a bit of history for the
components' issues as well (those that carry the odd version numbers) so
we can get a clean JIRA project for the ServiceMix 3 container again.
Regards,
Gert
Gert Vanthienen wrote:
L.S.,
If we look at the ServiceMix 3 JIRA project, the list of releases in
there is getting very long and very hard to work with. I know we
discussed this before, but I really think it makes sense to make a
separate JIRA project or projects for the components now.
One solution would be to create a single JIRA project for all the
components. Because we can release components independently, the
version numbers on the components will be going out of sync. One way
to handle this, is by using the same versioning scheme as we are using
now in SMX3, e.g. servicemix-ftp-2008.01 for version 2008.01 of
servicemix-ftp. On the other hand, we could also just create plain
version numbers like 2009.01 and then keeping the release open in JIRA
until all components have reached that version.
The other way to get passed this would be to create a JIRA project per
component. This way, we could use versions in JIRA just as we are
used to, but the overhead of setting this up would be quite big.
Which solution would people prefer? Are there any other suggestions
for solving this?
Regards,
Gert
