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...-GusOn Thu, Jun 13, 2019 at 3:23 PM David Smiley <firstname.lastname@example.org> wrote:+1 to your plan Jan.On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <email@example.com> 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.
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 logFor 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.com3. jun. 2019 kl. 19:56 skrev David Smiley <firstname.lastname@example.org>: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.On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <email@example.com> wrote:
> On Jun 3, 2019, at 6:41 AM, David Smiley <firstname.lastname@example.org> 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@example.com
For additional commands, e-mail: firstname.lastname@example.org