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 >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
