Issues with fixVersion = 8.1.2

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues with fixVersion = 8.1.2

Cassandra Targett
There are 7 resolved/closed issues with the fixVersion 8.1.2. Since that version was never released, it’s misleading to leave only a fixVersion that was never released. We know we can assume 8.2, but the average user may not.

Shouldn’t these all be changed to 8.2?

Cassandra
Reply | Threaded
Open this post in threaded view
|

Re: Issues with fixVersion = 8.1.2

david.w.smiley@gmail.com
Perhaps... but shouldn't we do likewise with CHANGES.txt (consistency)?
Regardless, I think branch_8_1's CHANGES.txt can be untouched since after all the code was committed there.


~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Aug 16, 2019 at 4:03 PM Cassandra Targett <[hidden email]> wrote:
There are 7 resolved/closed issues with the fixVersion 8.1.2. Since that version was never released, it’s misleading to leave only a fixVersion that was never released. We know we can assume 8.2, but the average user may not.

Shouldn’t these all be changed to 8.2?

Cassandra
Reply | Threaded
Open this post in threaded view
|

Re: Issues with fixVersion = 8.1.2

david.w.smiley@gmail.com
I was thinking about this some more.  What if the release manager has (yet another) step in which non-released intermediate versions are marked as-such in CHANGES.txt, and furthermore the associated JIRA issues are advanced in bulk to the Closed step.  That step could include an a comment about inclusion into the released version, so the JIRA issue mentions this.  I think it's okay to still have them associated to a non-released version because it's always possible that it could still get released.  Prematurely merging them is both extra work for the RM to do (more than what I describe above) and would eventually need to be un-done if there is such a release.

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Aug 16, 2019 at 5:13 PM David Smiley <[hidden email]> wrote:
Perhaps... but shouldn't we do likewise with CHANGES.txt (consistency)?
Regardless, I think branch_8_1's CHANGES.txt can be untouched since after all the code was committed there.


~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Aug 16, 2019 at 4:03 PM Cassandra Targett <[hidden email]> wrote:
There are 7 resolved/closed issues with the fixVersion 8.1.2. Since that version was never released, it’s misleading to leave only a fixVersion that was never released. We know we can assume 8.2, but the average user may not.

Shouldn’t these all be changed to 8.2?

Cassandra