Use of JIRA fixVersion

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Use of JIRA fixVersion

Jan Høydahl / Cominvent
Hi

This topic has been discussed several times before and various projects practice different rules for the fixVersion field.

Reason why I bring it up again is that I was researching the use of Yetus releasedocmaker[1] for generating release notes based on extra info added to jira issues as they are resolved. Attempting to run the tool for Solr v8.0.0 ({{releasedocmaker --project solr --version 8.0}}) resulted in a list of 255 features, but only 30 of those were actually new in 8.0!

Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to, i.e. new features normally gets “master (9.0)” and 8.2, while bugs normally gets 8.1.2 in addition. More serious bugs and security issues may in addition be flagged with 7.7.2.

An alternative fixVersion policy that I’d like us to consider, would be to mimic how we add CHANGES entries, i.e. only record the first version where a feature is introduced. For bug fixes we also in addition record any version where we backport the fix. This is because there is not a strict time line  with increasing versions once a release has happened in a newer major version branch. I.e. once 9.0 is released we cannot guarantee that 8.x.y is released before 9.x, so both need to be recorded. With this strategy, the only time it would make sense to have fixVersion=master(9.0) for a bug is if a bug in the 8.x line will not be fixed in a 8.x feature release. but the first fix will be in 9.0. With such a use of the field, a report for fixVersion=9.0 would list only new features and new bug fixes in 9.0. If we later change our mind and backport to 8.x we’d need to move changes entry and fixVersion from 9.0 to to 8.x.

If we switch to this policy you could not immediately see from jira whether a feature or bug fix perhaps only applied to 8.x and not 9.x. So we’d need some other way to see this. Three ways spring to mind: from yetus comments, from git log or from a separate jira field.

Another discussion that keeps coming back is when to add fixVersion in jira. Some argue it should not be added only when you actually push to a branch. But most of us add it based on intended (hoped) version before development starts. Should we write down a formal policy on this?

Jan

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Michael Sokolov-4
The main use I've had for this field: as a user, I want to know whether this bug or feature has been fixed or is available in the version I am using, and if not, which version I would need to upgrade to in order to get it. For this use case I think it's important to list versions on each branch it has been ported to, up to the first major version release that included it.

That seems to be at odds with the use case of automatically generating the changes file, where we want to pick a single branch. Both seem important, and I hope we can find a way, maybe by using some additional field, to support both. I don't have any productive suggestion how to do that, sorry, but just wanted to be clear about what we are trying to accomplish. Did I capture it?

Here's an idea: could we choose the highest branch that is not a .x branch as the fix branch for the purpose of the changes file?

On Sat, Jun 1, 2019, 2:58 PM Jan Høydahl <[hidden email]> wrote:
Hi

This topic has been discussed several times before and various projects practice different rules for the fixVersion field.

Reason why I bring it up again is that I was researching the use of Yetus releasedocmaker[1] for generating release notes based on extra info added to jira issues as they are resolved. Attempting to run the tool for Solr v8.0.0 ({{releasedocmaker --project solr --version 8.0}}) resulted in a list of 255 features, but only 30 of those were actually new in 8.0!

Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to, i.e. new features normally gets “master (9.0)” and 8.2, while bugs normally gets 8.1.2 in addition. More serious bugs and security issues may in addition be flagged with 7.7.2.

An alternative fixVersion policy that I’d like us to consider, would be to mimic how we add CHANGES entries, i.e. only record the first version where a feature is introduced. For bug fixes we also in addition record any version where we backport the fix. This is because there is not a strict time line  with increasing versions once a release has happened in a newer major version branch. I.e. once 9.0 is released we cannot guarantee that 8.x.y is released before 9.x, so both need to be recorded. With this strategy, the only time it would make sense to have fixVersion=master(9.0) for a bug is if a bug in the 8.x line will not be fixed in a 8.x feature release. but the first fix will be in 9.0. With such a use of the field, a report for fixVersion=9.0 would list only new features and new bug fixes in 9.0. If we later change our mind and backport to 8.x we’d need to move changes entry and fixVersion from 9.0 to to 8.x.

If we switch to this policy you could not immediately see from jira whether a feature or bug fix perhaps only applied to 8.x and not 9.x. So we’d need some other way to see this. Three ways spring to mind: from yetus comments, from git log or from a separate jira field.

Another discussion that keeps coming back is when to add fixVersion in jira. Some argue it should not be added only when you actually push to a branch. But most of us add it based on intended (hoped) version before development starts. Should we write down a formal policy on this?

Jan

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Gus Heck
In reply to this post by Jan Høydahl / Cominvent


Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to, i.e. new features normally gets “master (9.0)” and 8.2, while bugs normally gets 8.1.2 in addition. More serious bugs and security issues may in addition be flagged with 7.7.2.

I tend to use the field to indicate where I *did* port it to and where it can be found. As such I tend not to fill it in until it actually exists there (I 've committed). This avoids issues where a release happens before I have time to complete the fix. I think the "where do I find it" aspect that Mike mentions is more important than automating release notes. (Says the non pmc committer who hasn't had to do a release yet) ;)
Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Erick Erickson
In reply to this post by Jan Høydahl / Cominvent
bq. Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to

I don’t ;). In fact, I’d favor requiring this to be blank until a fix is committed. There are, as you’ve found, far too many instances where it’s filled in and completely inaccurate.

What I prefer to put in the fixVersion is the version numbers of all the branches I ported the fix to. There are things we put in, say, 8x that never get into the next major version. How would we know which ones those are?

Can the build tool get clever with a query about requiring the JIRA to be closed before using fixVersion at all?

Erick

> On Jun 1, 2019, at 11:58 AM, Jan Høydahl <[hidden email]> wrote:
>
> Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Ishan Chattopadhyaya
I put in the fix version after commit as well. 

In fact, in SOLR-11876, someone had put in a fix version involving a backport before I committed (which I didn't notice) and I resolved it without actually backporting. It caused a confusion, and resulted in a backport release to go out without the fix. ☹️

On Sun, 2 Jun, 2019, 8:29 PM Erick Erickson, <[hidden email]> wrote:
bq. Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to

I don’t ;). In fact, I’d favor requiring this to be blank until a fix is committed. There are, as you’ve found, far too many instances where it’s filled in and completely inaccurate.

What I prefer to put in the fixVersion is the version numbers of all the branches I ported the fix to. There are things we put in, say, 8x that never get into the next major version. How would we know which ones those are?

Can the build tool get clever with a query about requiring the JIRA to be closed before using fixVersion at all?

Erick

> On Jun 1, 2019, at 11:58 AM, Jan Høydahl <[hidden email]> wrote:
>
> Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

david.w.smiley@gmail.com
Thanks for raising this thread Jan.  I agree with Jan's proposal -- it is what I already do.  And based on some responses here, what some others do as well.  And as some others here have stated, I agree that we should try to only populate the fixVersion when resolving the issue (what I already do, usually.  This isn't a big deal though; I review this on every issue resolution that I do.


If someone wants to know what branches an issue was committed to, then review the bot comments to find out.  This is what I do -- I trust those comments more than I trust people to fill out JIRA metadata accurately/meaningfully :-)

Mike Sokolov said:
> The main use I've had for this field: as a user, I want to know whether this bug or feature has been fixed or is available in the version I am using, and if not, which version I would need to upgrade to in order to get it. For this use case I think it's important to list versions on each branch it has been ported to, up to the first major version release that included it.

Naturally this use case is important but I fail to see how our proposed approach fails to address it.  Maybe your point is about your intuition/assumptions on what fixVersion=7.2 (for example) means (to you)?  Some will get that, and some won't... yet would be confused by also fixVersion=master so I suppose it's impossible to satisfy everyone's intuitions about what the semantics mean.

~ David Smiley
Apache Lucene/Solr Search Developer


On Sun, Jun 2, 2019 at 1:35 PM Ishan Chattopadhyaya <[hidden email]> wrote:
I put in the fix version after commit as well. 

In fact, in SOLR-11876, someone had put in a fix version involving a backport before I committed (which I didn't notice) and I resolved it without actually backporting. It caused a confusion, and resulted in a backport release to go out without the fix. ☹️

On Sun, 2 Jun, 2019, 8:29 PM Erick Erickson, <[hidden email]> wrote:
bq. Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to

I don’t ;). In fact, I’d favor requiring this to be blank until a fix is committed. There are, as you’ve found, far too many instances where it’s filled in and completely inaccurate.

What I prefer to put in the fixVersion is the version numbers of all the branches I ported the fix to. There are things we put in, say, 8x that never get into the next major version. How would we know which ones those are?

Can the build tool get clever with a query about requiring the JIRA to be closed before using fixVersion at all?

Erick

> On Jun 1, 2019, at 11:58 AM, Jan Høydahl <[hidden email]> wrote:
>
> Currently we tag issues with fixVersion before commit, to indicate what BRANCHES we intend to commit to


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Erick Erickson


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

david.w.smiley@gmail.com
Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Jan Høydahl / Cominvent
Trying to reach a conclusion (or perhaps a vote) on this.

Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.

TypeCommitted tofixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Featurebranch_8x8.28.2
Bugfixmastermaster (9.0)none (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, branch_8_18.1.2, 8.28.1.2, 8.2
Bugfixbranch_8x8.28.2
Bugfixbranch_8_18.1.28.1.2
Bugfixbranch_8x, branch_7_77.7.3, 8.27.7.3, 8.2

In addition to this, we should all wait until commit time with setting fixVersion.

To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. 
For features, if it is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. jun. 2019 kl. 19:56 skrev David Smiley <[hidden email]>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Erick Erickson
I still prefer fixVersion to reflect every code line the change has been made to, but I won’t foam at the mouth about it.

I think my minor quibble is with the “unreleased bug” bit in CHANGES.txt. I’d rather see those fixes in CHANGES.txt too on the theory that it’s not clear it’s totally unreleased or just recently found….

FWIW,
Erick

> On Jun 13, 2019, at 5:39 AM, Jan Høydahl <[hidden email]> wrote:
>
> Trying to reach a conclusion (or perhaps a vote) on this.
>
> Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.
>
> Type Committed to fixVersion CHANGES.txt section
> Feature master master (9.0) 9.0
> Feature master, branch_8x 8.2 8.2
> Feature branch_8x 8.2 8.2
> Bugfix master master (9.0) none (unreleased bug)
> Bugfix master, branch_8x 8.2 8.2
> Bugfix master, branch_8x, branch_8_1 8.1.2, 8.2 8.1.2, 8.2
> Bugfix branch_8x 8.2 8.2
> Bugfix branch_8_1 8.1.2 8.1.2
> Bugfix branch_8x, branch_7_7 7.7.3, 8.2 7.7.3, 8.2
>
> In addition to this, we should all wait until commit time with setting fixVersion.
>
> To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x.
> For features, if it is unclear whether master has the commit, check gitbot log or git log
> For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>> 3. jun. 2019 kl. 19:56 skrev David Smiley <[hidden email]>:
>>
>> Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:
>>
>>
>> > On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>> >
>> > If someone wants to know what branches an issue was committed to, then review the bot comments to find out.
>>
>> What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?
>>
>> A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

david.w.smiley@gmail.com
In reply to this post by Jan Høydahl / Cominvent
+1 to your plan Jan.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <[hidden email]> wrote:
Trying to reach a conclusion (or perhaps a vote) on this.

Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.

TypeCommitted tofixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Featurebranch_8x8.28.2
Bugfixmastermaster (9.0)none (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, branch_8_18.1.2, 8.28.1.2, 8.2
Bugfixbranch_8x8.28.2
Bugfixbranch_8_18.1.28.1.2
Bugfixbranch_8x, branch_7_77.7.3, 8.27.7.3, 8.2

In addition to this, we should all wait until commit time with setting fixVersion.

To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. 
For features, if it is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. jun. 2019 kl. 19:56 skrev David Smiley <[hidden email]>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Gus Heck
FWIW I tend to agree with Erick here on both his points, but the second one more strongly than the first. The first I can live with either way really so long as it's clearly documented somewhere (besides this thread). 

If we don't update the changes in master for bug fixes when we're committing, who's going to go collect and add them later? I'm not sure I'm that big a fan of generating changes... I haven't looked at Yetus specifically but I suspect that this will just leave us with the title from the Jira, and often some additional detail for changes is worthwhile beyond what the title says. So if we create a field in Jira that is the Changes text, and make it required in the resolution screen fine to generate from that, but I think there's real value in the current system because you wind up writing a final short 1-4 line summary focused on "what the user needs to know" 

Also line 3, the feature only in 8x (but not master) is a very odd case in that table, I'm not sure when that would happen? could happen for a bug that is fixed by other changes in master, but for a feature? 

Also if we aren't marking branches explicitly maybe the 9.0 (master) tag should say 9.0 (unreleased)? Sure most developers know master is typically unreleased, but why add that mental leap. It's possible that someone less technical, or who is a student will stumble in from a link on SO...

-Gus

On Thu, Jun 13, 2019 at 3:23 PM David Smiley <[hidden email]> wrote:
+1 to your plan Jan.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <[hidden email]> wrote:
Trying to reach a conclusion (or perhaps a vote) on this.

Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.

TypeCommitted tofixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Featurebranch_8x8.28.2
Bugfixmastermaster (9.0)none (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, branch_8_18.1.2, 8.28.1.2, 8.2
Bugfixbranch_8x8.28.2
Bugfixbranch_8_18.1.28.1.2
Bugfixbranch_8x, branch_7_77.7.3, 8.27.7.3, 8.2

In addition to this, we should all wait until commit time with setting fixVersion.

To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. 
For features, if it is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. jun. 2019 kl. 19:56 skrev David Smiley <[hidden email]>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




--
Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Adrien Grand
+1 to Jan's proposal about not adding master when changes are also pushed to the previous major, I like the additional consistency with our CHANGES.txt.

I'm less sure about requiring that the fix version is not set before resolving the issue, I have used this in combination with the blocker label to mean that an issue needs to be addressed before releasing, sometimes it will be the next minor, sometimes the next major. For the record, the ReleaseTodo[1] recommends to check for blockers by filtering by priority and fixVersion.


On Fri, Jun 14, 2019 at 11:30 PM Gus Heck <[hidden email]> wrote:
FWIW I tend to agree with Erick here on both his points, but the second one more strongly than the first. The first I can live with either way really so long as it's clearly documented somewhere (besides this thread). 

If we don't update the changes in master for bug fixes when we're committing, who's going to go collect and add them later? I'm not sure I'm that big a fan of generating changes... I haven't looked at Yetus specifically but I suspect that this will just leave us with the title from the Jira, and often some additional detail for changes is worthwhile beyond what the title says. So if we create a field in Jira that is the Changes text, and make it required in the resolution screen fine to generate from that, but I think there's real value in the current system because you wind up writing a final short 1-4 line summary focused on "what the user needs to know" 

Also line 3, the feature only in 8x (but not master) is a very odd case in that table, I'm not sure when that would happen? could happen for a bug that is fixed by other changes in master, but for a feature? 

Also if we aren't marking branches explicitly maybe the 9.0 (master) tag should say 9.0 (unreleased)? Sure most developers know master is typically unreleased, but why add that mental leap. It's possible that someone less technical, or who is a student will stumble in from a link on SO...

-Gus

On Thu, Jun 13, 2019 at 3:23 PM David Smiley <[hidden email]> wrote:
+1 to your plan Jan.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <[hidden email]> wrote:
Trying to reach a conclusion (or perhaps a vote) on this.

Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.

TypeCommitted tofixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Featurebranch_8x8.28.2
Bugfixmastermaster (9.0)none (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, branch_8_18.1.2, 8.28.1.2, 8.2
Bugfixbranch_8x8.28.2
Bugfixbranch_8_18.1.28.1.2
Bugfixbranch_8x, branch_7_77.7.3, 8.27.7.3, 8.2

In addition to this, we should all wait until commit time with setting fixVersion.

To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. 
For features, if it is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. jun. 2019 kl. 19:56 skrev David Smiley <[hidden email]>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




--


--
Adrien
Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

Mark Miller-3
Can we address this in JIRA? In the past I've seen this handled in JIRA by also having a 'target' version field - this is the intended version you want to land in and you set it right away. Things were configured so you could only set the fix version when you resolved I think. Then you would use target for release blockers and such. Fix would just tell you what it's actually in.

On Mon, Jun 17, 2019 at 4:49 AM Adrien Grand <[hidden email]> wrote:
+1 to Jan's proposal about not adding master when changes are also pushed to the previous major, I like the additional consistency with our CHANGES.txt.

I'm less sure about requiring that the fix version is not set before resolving the issue, I have used this in combination with the blocker label to mean that an issue needs to be addressed before releasing, sometimes it will be the next minor, sometimes the next major. For the record, the ReleaseTodo[1] recommends to check for blockers by filtering by priority and fixVersion.


On Fri, Jun 14, 2019 at 11:30 PM Gus Heck <[hidden email]> wrote:
FWIW I tend to agree with Erick here on both his points, but the second one more strongly than the first. The first I can live with either way really so long as it's clearly documented somewhere (besides this thread). 

If we don't update the changes in master for bug fixes when we're committing, who's going to go collect and add them later? I'm not sure I'm that big a fan of generating changes... I haven't looked at Yetus specifically but I suspect that this will just leave us with the title from the Jira, and often some additional detail for changes is worthwhile beyond what the title says. So if we create a field in Jira that is the Changes text, and make it required in the resolution screen fine to generate from that, but I think there's real value in the current system because you wind up writing a final short 1-4 line summary focused on "what the user needs to know" 

Also line 3, the feature only in 8x (but not master) is a very odd case in that table, I'm not sure when that would happen? could happen for a bug that is fixed by other changes in master, but for a feature? 

Also if we aren't marking branches explicitly maybe the 9.0 (master) tag should say 9.0 (unreleased)? Sure most developers know master is typically unreleased, but why add that mental leap. It's possible that someone less technical, or who is a student will stumble in from a link on SO...

-Gus

On Thu, Jun 13, 2019 at 3:23 PM David Smiley <[hidden email]> wrote:
+1 to your plan Jan.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <[hidden email]> wrote:
Trying to reach a conclusion (or perhaps a vote) on this.

Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.

TypeCommitted tofixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Featurebranch_8x8.28.2
Bugfixmastermaster (9.0)none (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, branch_8_18.1.2, 8.28.1.2, 8.2
Bugfixbranch_8x8.28.2
Bugfixbranch_8_18.1.28.1.2
Bugfixbranch_8x, branch_7_77.7.3, 8.27.7.3, 8.2

In addition to this, we should all wait until commit time with setting fixVersion.

To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. 
For features, if it is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. jun. 2019 kl. 19:56 skrev David Smiley <[hidden email]>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




--


--
Adrien


--
Reply | Threaded
Open this post in threaded view
|

Re: Use of JIRA fixVersion

david.w.smiley@gmail.com
"I'm less sure about requiring that the fix version is not set before resolving the issue"   Yeah, this aspect I don't think is particularly important either way.  We can establish a preference to leave blank until release time, but say Blocker issues are a good exception.

It'd be nice to have internal dev docs for us to write these down in so we can refer to them, particularly to share with new committers as well.  Were you planning to do this Jan?

~ David Smiley
Apache Lucene/Solr Search Developer


On Wed, Jun 19, 2019 at 12:22 PM Mark Miller <[hidden email]> wrote:
Can we address this in JIRA? In the past I've seen this handled in JIRA by also having a 'target' version field - this is the intended version you want to land in and you set it right away. Things were configured so you could only set the fix version when you resolved I think. Then you would use target for release blockers and such. Fix would just tell you what it's actually in.

On Mon, Jun 17, 2019 at 4:49 AM Adrien Grand <[hidden email]> wrote:
+1 to Jan's proposal about not adding master when changes are also pushed to the previous major, I like the additional consistency with our CHANGES.txt.

I'm less sure about requiring that the fix version is not set before resolving the issue, I have used this in combination with the blocker label to mean that an issue needs to be addressed before releasing, sometimes it will be the next minor, sometimes the next major. For the record, the ReleaseTodo[1] recommends to check for blockers by filtering by priority and fixVersion.


On Fri, Jun 14, 2019 at 11:30 PM Gus Heck <[hidden email]> wrote:
FWIW I tend to agree with Erick here on both his points, but the second one more strongly than the first. The first I can live with either way really so long as it's clearly documented somewhere (besides this thread). 

If we don't update the changes in master for bug fixes when we're committing, who's going to go collect and add them later? I'm not sure I'm that big a fan of generating changes... I haven't looked at Yetus specifically but I suspect that this will just leave us with the title from the Jira, and often some additional detail for changes is worthwhile beyond what the title says. So if we create a field in Jira that is the Changes text, and make it required in the resolution screen fine to generate from that, but I think there's real value in the current system because you wind up writing a final short 1-4 line summary focused on "what the user needs to know" 

Also line 3, the feature only in 8x (but not master) is a very odd case in that table, I'm not sure when that would happen? could happen for a bug that is fixed by other changes in master, but for a feature? 

Also if we aren't marking branches explicitly maybe the 9.0 (master) tag should say 9.0 (unreleased)? Sure most developers know master is typically unreleased, but why add that mental leap. It's possible that someone less technical, or who is a student will stumble in from a link on SO...

-Gus

On Thu, Jun 13, 2019 at 3:23 PM David Smiley <[hidden email]> wrote:
+1 to your plan Jan.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <[hidden email]> wrote:
Trying to reach a conclusion (or perhaps a vote) on this.

Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.

TypeCommitted tofixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Featurebranch_8x8.28.2
Bugfixmastermaster (9.0)none (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, branch_8_18.1.2, 8.28.1.2, 8.2
Bugfixbranch_8x8.28.2
Bugfixbranch_8_18.1.28.1.2
Bugfixbranch_8x, branch_7_77.7.3, 8.27.7.3, 8.2

In addition to this, we should all wait until commit time with setting fixVersion.

To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. 
For features, if it is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. jun. 2019 kl. 19:56 skrev David Smiley <[hidden email]>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[hidden email]> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <[hidden email]> wrote:
>
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




--


--
Adrien


--