Thanks Steve for the guidance! Since LUCENE-7676 and SOLR-10083 were both (unreleased) 6.5.0 to 6.4.2 backports I have gone ahead and moved the CHANGES.txt entries on both branch_6x and master (after the branch_6_4 commit itself).
My plan for https://issues.apache.org/jira/browse/SOLR-10192 is to have it in the 6.4.2 section from the outset (if it goes into the 6.4.2 release that is). Christine ----- Original Message ----- From: dev@lucene.apache.org To: dev@lucene.apache.org At: 02/22/17 13:42:54 Hi Christine, > On Feb 22, 2017, at 5:10 AM, Christine Poerschke (BLOOMBERG/ LONDON) > <cpoersc...@bloomberg.net> wrote: > > What process do people typically follow w.r.t. updating CHANGES.txt on > branch_6x and master in those circumstances e.g. do the entries move from the > 6.5 to the 6.4.2 section or are they duplicated in the 6.4.2 section or is it > taken care of somehow overall (for master and branch_6x but not branch_6_4) > as part of the RC process? It’s typically a mess: some people move CHANGES entries on the unstable and stable branches when they backport to point releases, some don't. There’s a TODO item for the release manager to sync CHANGES post-release: <https://wiki.apache.org/lucene-java/ReleaseTodo#Synchronize_CHANGES.txt>. It’s complicated by the fact that entries should never be removed from *released* versions, so issues backported to a point release for an older branch typically don’t ever trigger *removal* of duplicate entries elsewhere, just copy/paste of the point release’s section into the stable & unstable branches’ CHANGES. -- Steve www.lucidworks.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
