@Dawid: I remember that discussion, and I think things were fixed for the issue
back then.
My concern right now is that we will end up in a similar situation again with
everyone interpreting the fixVersion differently.
@Erick
Here’s my issue with that approach. Say I commit something that would be
released with 7.0 but obviously, I also commit to master at this point. Going
with your approach here are the fix versions I’ll end up with on the JIRA -
master (8.0), 7.1, and 7.0.
This confuses me, as anything that has a 7.0 fix version shouldn’t have
anything else from the 7x line. Also, it shouldn’t have anything from a line
greater than that i.e. master (8.0) as it is obvious to me that there can not
be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.
Also, from my understanding, a fix version of 7.1 would mean that the first
time this was released on the 7x line was 7.1 (which wouldn’t be the case here).
Yes, things would work differently for bug fix releases, but I’m talking about
the major release version here.
Here’s my suggestion:
- For a fix that will be released with a major version, just mention the major
version
- For a minor version
- master (current version + 1)
- minor version release that would have this fix
- all prior bug fix releases, when this is back-ported to older branches
- Bug fix release
- The only case when a fix is released with such a release, is when
- The issue was introduced by a minor version release right
before this release AND
- There was no other minor/major release since this issue was
introduced.
- In such a case, the fix version should only have the bug fix version,
and not master, etc.
What would also be useful here is specifying the ‘Affects Version’ but in my
experience, this gets tough to figure at times for bug fixes, and doesn’t
generally make sense for new features/enhancements.
If there’s anything else, I’d be happy to just go with whatever everyone wants
to follow as long as it makes things easier to understand and manage.
-Anshum
> On Jul 5, 2017, at 2:13 PM, Erick Erickson <erickerick...@gmail.com> wrote:
>
> I'm just including a fix version for each push I make. I.e.
>
> If I push to master I'll add "master (8.0)".
> If I push to 7x, at this point I'll add 7.1
> If I push to 7_0 I'll add 7.0
> If I push to 6x I'll add 6.7
> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
>
> I think one push == one label is unambiguous. You do have to realize
> that if there may never be, say, a 6.6.1 in my example. But we do
> remove the onus of people having to figure out what a fix version of
> plain "master" or "7x" means.
>
> FWIW
> Erick
>
>
>
> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss <dawid.we...@gmail.com> wrote:
>> There's been a fairly recent discussion about it on the mailing list
>> (David Smiley and were involved in that discussion, among other
>> people). There are many different takes on how to handle fix-for and
>> branches. I don't think we can find the "best" strategy, although
>> perhaps we can agree on something project-specific. I've expressed my
>> opinion on that previous post, but I'm open to any strategy.
>>
>> Dawid
>>
>> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta <ansh...@apple.com> wrote:
>>> Hi,
>>>
>>> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
>>> are being committed right now. I think it makes sense for the fixVersion to
>>> just be 7.0, and nothing else for everything that is going into branch_7_0,
>>> instead of being both 7.0, and master (8.0).
>>>
>>> Any thoughts?
>>>
>>> -Anshum
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
