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
