Den tis 14 juli 2026 kl 17:40 skrev <[email protected]>: > Author: kotkov > Date: Tue Jul 14 15:40:10 2026 > New Revision: 1936137 > > Log: > * branches/1.15.x/STATUS: Add separate sections for release blocker > candidates > and changes that cannot go to a later 1.15.x release (we used this > pattern > in 1.9.x/STATUS, should be useful here as well). > > Put all current nominations into the "other" section. > > Modified: > subversion/branches/1.15.x/STATUS > > Modified: subversion/branches/1.15.x/STATUS > > ============================================================================== > --- subversion/branches/1.15.x/STATUS Tue Jul 14 15:38:15 2026 > (r1936136) > +++ subversion/branches/1.15.x/STATUS Tue Jul 14 15:40:10 2026 > (r1936137) > @@ -12,8 +12,14 @@ delay a release, etc. > > Status of 1.15.0: > > -Candidate changes: > -================== > +Release blockers for 1.15.0: > +============================ > + > +Candidate changes that cannot go into a later 1.15.x: > +===================================================== > + > +Other candidate changes: > +======================== >
These headlines break the backport scripts (libraries /tools/dist/backport/*.py and the associated scripts in /tools/dist/). More specifically, /tools/dist/backport/status.py (the library responsible for parsing STATUS) is looking for the headline "Candidate changes:". Any unknown headlines are kept as-is, so at least it didn't munch any existing nominations. I tried this out in the recent 1936154-1936156. When the script added the nomination, it looked for a "Candidate changes:" headline and when one wasn't found, it added one last (see [1]). I've updated the script in r1936159, changing it to first look for Other candidate changes and, if that fails, look for Candidate changes (adding the header if not found). I think that should work well enough, we can support either the "x.y.0 format" (as it is currently) or "z.y.z with z>0". The script doesn't support adding a nomination as a release blocker or as a "cannot go into a later.." but I think it isn't very high priority. merge-approved-backports.py seems to work fine, it only looks for "Approved changes" and keep the remaining headers. It doesn't care about the order of the headers. r1936156 was done by running merge-approved-backports.py. Does this change look ok? Cheers, Daniel [1] https://demo-server.visualsvn.com/!/#asf/view/r1924264/subversion/trunk/tools/dist/nominate-backport.py?line=221
