Hi I just wanted to have a mail about something similar…as at the moment I am removing the “fix version” from stories that are 2-3 years old and no activity on them!
I think your definition is the correct one! I like the idea to not assign any fix version when story is created, it should be assigned only when story is done (PR got merged)! Regards, Adam > On 2025. Mar 14., at 16:33, James Dailey <jamespdai...@gmail.com> wrote: > > I wonder if we are on the same page? > > My definition for the field in Jira tickets called "Fix version/s:" is that > it represents either: > - 1) the planned release version (where it fits on the roadmap) > or - 2) the actual release in which the ticket was resolved. > > (it does not represent the version that you are Fixing, but the version in > which something is fixed) > > While we should aim for (1) we are actually only doing (2) for now. > > Thus, the way for us to manage this would be, > * when creating a ticket, do not assign a planned release "fix version", > leave it as "none". You don't know. We don't know if/when someone will work > on it. > * when working on the ticket resolution, check the current release and > increment by one. Thus, if the current release is 1.11.0, then assume that > your fix will go into 1.12.0 (check the listserv to see if there is any > planned release coming up) > > A couple of implications: > - When doing the release of a patch, we can then filter on 1.12 and status = > done and include the changeset. > - When doing a full release, we can then pull those that are !done (not done) > and 1.12.0 in this field and then interrogate whether they are fully done or > need to be moved to the next release or to "none". > > Are we in agreement ?
