L.S., A separate JIRA project has been set up and components issues have been moved to https://issues.apache.org/activemq/browse/SMXCOMP. The 2008.01 and 2009.01 versions have been removed from our main ServiceMix JIRA, so we have a more manageable list of versions there now as well.
Thanks to Lars and Jean-Baptiste for helping me to get all the issues moved over the weekend! Gert Gert Vanthienen wrote: > > 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 >>>> >>>> >>>> >>> >> >> >> >> > > > > ----- > --- > Gert Vanthienen > http://gertvanthienen.blogspot.com > ----- --- Gert Vanthienen http://gertvanthienen.blogspot.com -- View this message in context: http://www.nabble.com/-DISCUSS--Separate-JIRA-project%28s%29-for-Components-tp21980838p22025458.html Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
