> > How do you know if it is the version for planning or if that has been > really > fixed already? >
That is JIRA Status + Fix version. If an issue is fixed and the Fix Version is 0.10, then this issue is fixed in 0.10. If you have a bug that needs to be backported to a previous > release or forward ported to the master the jira is left open. The release > info in jira will show that it has not been fixed yet while it is for that > release. > Not quite sure about this case. IMO, if a PR is committed, we need to close the JIRA with a proper Fix Version set. If the PR has been ported to more than one version, we set the Fix Version accordingly to several versions. I am not sure why we would keep the JIRA open when we have the PR committed already. On Wed, Apr 28, 2021 at 5:56 PM Wilfred Spiegelenburg <[email protected]> wrote: > The problem with using one field for planning and showing where it is > committed is that you get into trouble when you have multiple releases. How > do you know if it is the version for planning or if that has been really > fixed already? If you have a bug that needs to be backported to a previous > release or forward ported to the master the jira is left open. The release > info in jira will show that it has not been fixed yet while it is for that > release. > > The release tool is not designed to be used with multiple releases in mind. > > Wilfred > > On Thu, 29 Apr 2021 at 04:26, Weiwei Yang <[email protected]> wrote: > > > Hi Wilfred > > > > If you look at the JIRA document: > > https://www.atlassian.com/agile/tutorials/versions. > > > > *Fix version* is the version where you plan on releasing a feature or > > bugfix to customers. This field is used for release planning, monitoring > > progress and velocity, and is used widely in reporting. This is most > likely > > the field you want. > > > > You can also find a similar discussion here: > > > https://stackoverflow.com/questions/37874420/use-target-version-for-release-planning-in-jira > > . > > If we follow this instruction, we can nicely track the release plan and > > activities here. But if we do not set the Fix Version, you see the > > In-progress and Issues-todo are both empty. > > > > [image: YUNIKORN__0_11_-_ASF_JIRA.png] > > > > Instead of creating customized filters, we should rely on the JIRA > > *release* tool to plan and track our releases. > > > > On Wed, Apr 28, 2021 at 1:06 AM Wilfred Spiegelenburg < > [email protected]> > > wrote: > > > >> Hi all, > >> > >> There are multiple fields that can be set with versions in jira. Two are > >> used in YuniKorn: > >> * Fix version/s > >> * Target Version > >> > >> The Target Version is not shown by default on the pages but should be > used > >> to mark a jira to be targeted for a specific release. Currently that is > >> 0.11. The description of the Target Version field is given as: > >> The versions where this patch is intended to be committed. Use "Fix > >> Version" to note where it actually has been committed. > >> > >> That is exactly what I was taught when I started using bug tracking > >> systems. The Fix Version/s is set when the jira is resolved or closed > and > >> the code is committed and the issue is fixed in that version. > >> > >> We had 29 jiras that are open marked with a fix version of 0.11. I have > >> moved them to a target version. Please do not set a fix version if the > >> code > >> has not been committed, use the target version field. > >> There are two public searches available that can be used to check what > is > >> going on for the current release: > >> target for next release: > >> https://issues.apache.org/jira/issues/?filter=12348416 > >> fixed in next release: > >> https://issues.apache.org/jira/issues/?filter=12350521 > >> > >> These two searches are shown as the project shortcuts for anyone to > >> access. > >> > >> Wilfred > >> > > >
