> "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 nic
"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 int
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 ta
+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
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, wh
+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 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 mos
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 unrele
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 tofixVersion CHANGES.txt section
Feature master master (9.0)9.0
Feature master, branch_8x 8
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 a
> On Jun 3, 2019, at 6:41 AM, David Smiley 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 m
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
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 fi
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.
Wha
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 t
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
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 th
16 matches
Mail list logo
