Julian Foad wrote on Tue, Nov 19, 2019 at 17:18:23 +0000:
> Daniel Shahaf wrote:
> > julianfoad_at_apache.org wrote on Mon, 18 Nov 2019 16:31 +00:00:
> > > Author: julianfoad
> > > Date: Mon Nov 18 16:31:45 2019
> > > New Revision: 1869981
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1869981&view=rev
> > > Log:
> > > * tools/dist/release.py (recommended_release): Remove TODO: didn't make sense.
> >
> > The point of that TODO is that instead of hardcoding
> > «recommended_release» in the source code, we can derive it from the version number being
> > rolled and the version numbers currently available for download. This way, we won't have to
> > manually update «recommended_release» as part of the release process.
>
> The version being rolled is any version we want to roll, probably but not
> necessarily a supported version (it's not forbidden to use this tool to roll
> an unsupported version), and certainly not necessarily the currently
> recommended version.
>
> The set of versions currently available for download is one of the outputs
> that we are possibly intending to change during the release process
> (depending on what sort of release it is, or maybe it's a test roll and not
> a release at all). One of the things release.py does is help us generate
> the 'downloads' page.
>
> The definition of what is the currently "recommended" release is an input to
> the "release.py" part of the release management process.
>
> What am I missing?
Can't we just do this? —
def recommended_release(version_being_rolled, versions_on_dist_release):
stable_versions_on_dist_release = filter(lambda v: not v.is_prerelease(), versions_on_dist_release)
if version_being_rolled.is_prerelease():
return max(stable_versions_on_dist_release)
else:
return max(list(stable_versions_on_dist_release) + [version_being_rolled])
I don't see what case it breaks in, out of all the ones you enumerate (1.8.0,
1.14.0-nightly, 1.14.0-rc1, 1.14.0 GA, 1.10.7, 1.8.0).
Received on 2019-11-19 18:36:35 CET