incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Riccomini <>
Subject Airflow voting on release artifacts
Date Mon, 24 Apr 2017 20:18:55 GMT
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.


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