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 <[email protected]> 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. > > [1] https://wiki.apache.org/lucene-java/ReleaseTodo > > On Fri, Jun 14, 2019 at 11:30 PM Gus Heck <[email protected]> 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 <[email protected]> >> wrote: >> >>> +1 to your plan Jan. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <[email protected]> >>> 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 <[email protected]>: >>>> >>>> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> > On Jun 3, 2019, at 6:41 AM, David Smiley <[email protected]> >>>>> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> > > > -- > Adrien > -- - Mark http://about.me/markrmiller
