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 <criccom...@apache.org> wrote: > 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 >
