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 http://www.linkedin.com/in/davidwsmiley On Fri, Aug 16, 2019 at 5:13 PM David Smiley <[email protected]> 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. > > At least http://lucene.apache.org/solr/8_2_0/changes/Changes.html > includes 8.1.2 > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Aug 16, 2019 at 4:03 PM Cassandra Targett <[email protected]> > 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 >> >
