incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <>
Subject Re: Airflow voting on release artifacts
Date Tue, 25 Apr 2017 00:11:57 GMT
Do you need to cut a vote with something named rc?  Why can't you just use
the version #?

On Mon, Apr 24, 2017 at 4:18 PM Chris Riccomini <>

> Hey all,
> We've had a question arise in the Airflow project. We're currently cutting
> release candidates (RCs), and voting on those. These RCs contain an
> artifact with the suffix -rc0, -rc1, etc. The problem with this is that the
> final RC that passes the vote still has an -rcX in its version number. To
> get around this, the release manager has just been rebuilding the .asc,
> .sha, etc, and publishing this new artifact as the final release.
> Hitesh recently raised the issue that the artifact that passes the vote
> MUST be the one that we actually release. The problem with this is that it
> would force us to publish multiple RCs with the exact same version number.
> This is a terrible experience from a developer and user point of view.
> Airflow is a Python project, and many users pip install various versions of
> Airflow to test things out. Having multiple RCs with the same version
> number is going to make it really difficult to keep things straight, both
> during the VOTE, and afterwards.
> Based on a cursory look, it seems that other projects handle this problem
> in one of three ways:
> * Double vote (the final RC gets voted AGAIN, this time, with proper
> naming)
> * Rename/rebuild after final vote (This is what Airflow is doing, and Beam
> does this, I believe)
> * All RCs have the exact same version number
> Most Java projects are just publishing multiple RCs with the exact same
> version number. This seems bad from a general software engineering
> perspective, since it's going to cause build cache issues (e.g. .mvn
> already contains version 1.2.3, even though a new RC with the same version
> should be installed). Beam does seem to be using -SNAPSHOT releases in Java
> for RCs, which is CLOSER to what we've been doing in Airflow (-rc0, -rc1,
> etc), and they seem to be renaming after the release, just like we were.
> What's the guidance here? We seem to have two requirements that are at odds
> with eachtother:
> 1) The RC artifact that we vote on is the one that we release
> 2) We have real version numbers for RCs which are independent of one
> another so build systems, dependency managements systems, and package
> management systems can properly handle them.
> Any help or thoughts would be appreciated.
> Cheers,
> Chris

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message