Guillaume,
Creating the release notes wouldn't be a real problem, I think. We're
not doing this every week and we can always filter for a list of issues
being solved for one specific component and one specific version and
export that to text or something.
However, you're right about the other thing... Confusing people about
which version a fix should/would go in would be very bad indeed. If we
get inconsistent release information in JIRA, it will become impossible
to ever figure out if/when a user reported bug is getting fixed. We
should prefer confusing people with 50-something different versions
then, because at least that gives us the specific information we need
for helping them out.
Setting up a different project for every component right now would not
be that much more work -- the only overhead would be in creating the
projects themselves, we still need to create the same amount of versions
and move all the issues around anyway. I'm a bit worried that this will
scatter information around too much though and that it will become too
difficult to get an overview of what we're doing. Also, nobody is going
to notice that ActiveMQ and Camel are also around in this JIRA instance
if we will add about 25 projects in there ;)
So, unless there are any other thoughts, I'll set up a single project
with the required amount of versions to cover all the components over
the weekend.
Regards,
Gert
Guillaume Nodet wrote:
I'm not sure how we could go with a single version. Suppose we create
a version for 2009.01 and 2009.02. If we release one component with
2009.01, when a new JIRA is created, you will need to select a version
to fix the bug in, and you will end up choosing between 2 unreleased
versions. Another problem would be when we want to create the release
notes I guess. Having a single version would be nice because we would
not have a very long list of versions available, but it may very well
lead to inconsistencies if we are not very carefull to check the real
version when we fix a bug.
Though if we plan to later separate the components, using a single
version will be easier because we would not have to change those when
splitting the components.
2009/2/13 Gert Vanthienen <[email protected]>:
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
