[
https://issues.apache.org/jira/browse/LUCENE-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274412#comment-15274412
]
Hoss Man commented on LUCENE-7275:
----------------------------------
bq. Should we even have 6.x and 5.x versions at all?
Philosophically: Either we should *only* have 6.x and no "6.1" (and then "6.x"
gets renamed to "6.1" on release) or we should *only* have 6.1 (since we know
that is what the next version released from the 6x branch will be called).
(Either way we definitely shouldn't have a "5.x" version at this point)
6.1 seems like the better choice given that: it's really the only sane option
for what will be released off of branch_6x, it fits peoples mental models
better, and for "things that are going to be released relatively soon" it
probably makes more sense to end users looking at issues (as opposed to just
labeling it "6.x" and a user of 6.0 might wonder "is that in my release then?
my release is a 6.x release)
I think "master" is a special case in that, until we actually fork of a
development branch ("branch_7x") there's a lot more uncertainty to that branch
-- as we saw with the creation of branch_5x.
(But i do think a name like {{master (7.0)}} -- as in "committed to master,
which will probably be 7.0" is a better choice and a better reminder to all
devs in the future to rename it once a branch_7x _does_ get created, so we
don't have another cluster fuck like LUCENE-7271, which is why it's the name
i'm planning to use when i add back "master" in that issue ... but i digress)
bq. If we get rid of them, all affected issues (which may be a larger number
than those retrieved with the above query, since these versions could also have
been used in JIRA's "Affects Version/s" field) will need to be relabeled with
the appropriate version.
I think getting rid of them (5.x and 6.x) is probably the right call - any
information value to be had from issues that list them as "affects versions" is
probably non existent, and there's not going to be any clear cut and obvious
"easy win" in merging those versions into any other concrete versions -- we
just need to run a report on that query first, and then have the handful of
devs assigned to those ~40 issues to take a few minutes to review the list and
make sure the accurate fixVersion(s) is recorded.
> Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer
> to the correct version
> ----------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7275
> URL: https://issues.apache.org/jira/browse/LUCENE-7275
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Steve Rowe
>
> The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and
> {{5.x}} - there are 38 issues with these as fixVersion-s:
> https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x).
> Should we even have {{6.x}} and {{5.x}} versions at all?
> If we get rid of them, all affected issues (which may be a larger number than
> those retrieved with the above query, since these versions could also have
> been used in JIRA's "Affects Version/s" field) will need to be relabeled with
> the appropriate version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
