there are some that are assigned for 1.6 because we are not fixing them in 1.5. lets not touch those. we need to be able to assign to future versions. i think we can keep things assigned to 1.5.0 for things that need to be fixed before the final comes out and reassign them to milestones as we are fixing them. ie we need to be able to communicate:
this issue cannot be fixed in the next minor release - maybe because it breaks api this issue cannot be fixed in the next major release - maybe its outside of scope this issue is scheduled post next major release - starting to create the roadmap so i dont think fix versions are bad, what is bad is that people other then developers can assign them. -igor On Mon, Dec 20, 2010 at 8:56 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > On Mon, Dec 20, 2010 at 7:22 PM, Jeremy Thomerson <jer...@wickettraining.com >> wrote: > >> As just mentioned in another thread here, I seem to encounter what I >> think is a problem in how we're using JIRA every time I do a release. >> A lot of times, there are issues that have a "fix version == >> $releaseIAmBuilding", even though they are still open / unresolved. I >> thought that we didn't set a fix version until closing a ticket as >> fixed. Is that correct or am I mistaken? If it is correct, do we >> have any JIRA way of setting some rule to that effect? >> >> I think we discussed this a month ago. > The consensus was to remove the "fix for" property for all tickets but the > ones that need to be really fixed in that version (security, critical). > >> -- >> Jeremy Thomerson >> http://wickettraining.com >> Need a CMS for Wicket? Use Brix! http://brixcms.org >> >