You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by da...@apache.org on 2019/01/08 12:03:59 UTC
svn commit: r1850737 - /subversion/site/tools/upcoming.py
Author: danielsh
Date: Tue Jan 8 12:03:58 2019
New Revision: 1850737
URL: http://svn.apache.org/viewvc?rev=1850737&view=rev
Log:
* tools/upcoming.py
(DIST_RELEASE_URL): New constant.
(copyfrom_revision_of_previous_tag_of_this_stable_branch):
Determine the latest release by checking dist/release/, not by checking
tags, in order to also show changes that have been merged into a patch
release that has not been announced yet.
This change will cause tonight's bot run to effectively revert r1850708 (and
add Monday's merge to the output as well), re-adding all the merges that
went into 1.11.1 to the Web site — which is correct, since 1.11.1 has not yet
been published.
Modified:
subversion/site/tools/upcoming.py
Modified: subversion/site/tools/upcoming.py
URL: http://svn.apache.org/viewvc/subversion/site/tools/upcoming.py?rev=1850737&r1=1850736&r2=1850737&view=diff
==============================================================================
--- subversion/site/tools/upcoming.py (original)
+++ subversion/site/tools/upcoming.py Tue Jan 8 12:03:58 2019
@@ -18,6 +18,7 @@ import xml.etree.ElementTree as ET
SVN = os.getenv('SVN', 'svn')
LOG_SEPARATOR_LINE = ('-' * 72) + '\n'
+DIST_RELEASE_URL = 'https://dist.apache.org/repos/dist/release/subversion'
def copyfrom_revision_of_previous_tag_of_this_stable_branch():
"""Returns the copyfrom revision of the previous tag of the stable branch
@@ -25,8 +26,14 @@ def copyfrom_revision_of_previous_tag_of
### Doesn't work during the alpha/beta/rc phase; works only after 1.A.0 has been tagged
version_string = subprocess.check_output(['build/getversion.py', 'SVN', 'subversion/include/svn_version.h']).decode()
version_broken_down = list(map(int, version_string.split('.')))
- version_broken_down[-1] -= 1
- assert version_broken_down[-1] >= 0
+ files_list = subprocess.check_output([SVN, 'ls', '--', DIST_RELEASE_URL]).decode().splitlines()
+ while version_broken_down[-1] > 0:
+ version_broken_down[-1] -= 1
+ if any(x.startswith('subversion-' + '.'.join(map(str, version_broken_down)) + '.tar.')
+ for x in files_list):
+ break
+ else:
+ assert False, "Couldn't find last release preceding {!r}".format(version_string)
target = '^/subversion/tags/' + '.'.join(map(str, version_broken_down))
log_output = \
subprocess.check_output(
Re: svn commit: r1850737 - /subversion/site/tools/upcoming.py
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
danielsh@apache.org wrote on Tue, 08 Jan 2019 12:03 +0000:
> Log:
> * tools/upcoming.py
> (copyfrom_revision_of_previous_tag_of_this_stable_branch):
> Determine the latest release by checking dist/release/, not by checking
> tags, in order to also show changes that have been merged into a patch
> release that has not been announced yet.
>
> This change will cause tonight's bot run to effectively revert r1850708 (and
> add Monday's merge to the output as well), re-adding all the merges that
> went into 1.11.1 to the Web site — which is correct, since 1.11.1 has not yet
> been published.
There is still a minor race condition here: when 1.11.1 artifacts are
moved to dist/release/, the Website will stop showing merges that
went into 1.11.1 even before the download page and mirrors are
updated to 1.11.1.
I suppose we can live with that, but if anyone has ideas for improving
the situation...
Cheers,
Daniel
Re: svn commit: r1850737 - /subversion/site/tools/upcoming.py
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
danielsh@apache.org wrote on Tue, 08 Jan 2019 12:03 +0000:
> Log:
> * tools/upcoming.py
> (copyfrom_revision_of_previous_tag_of_this_stable_branch):
> Determine the latest release by checking dist/release/, not by checking
> tags, in order to also show changes that have been merged into a patch
> release that has not been announced yet.
>
> This change will cause tonight's bot run to effectively revert r1850708 (and
> add Monday's merge to the output as well), re-adding all the merges that
> went into 1.11.1 to the Web site — which is correct, since 1.11.1 has not yet
> been published.
There is still a minor race condition here: when 1.11.1 artifacts are
moved to dist/release/, the Website will stop showing merges that
went into 1.11.1 even before the download page and mirrors are
updated to 1.11.1.
I suppose we can live with that, but if anyone has ideas for improving
the situation...
Cheers,
Daniel