On 4/25/17, 1:43 AM, "Bolke de Bruin" <bdbr...@gmail.com> wrote:
>Hi Bertrand, > >> On 25 Apr 2017, at 09:04, Bertrand Delacretaz >><bdelacre...@codeconsult.ch> wrote: >> >> Hi, >> >> On Mon, Apr 24, 2017 at 10:18 PM, Chris Riccomini >><criccom...@apache.org> wrote: >>> ...Hitesh recently raised the issue that the artifact that passes the >>>vote >>> MUST be the one that we actually release... >> >> Yes in terms of having the same binary digests and signatures, but >> renaming the files is fine IMO, especially for removing an -rc suffix >> which makes total sense. I would just add that step to your release >> process documentation to make it clear. >> >>> ...Rename/rebuild after final vote (This is what Airflow is doing, and >>>Beam >>> does this, I believe)... >> >> I'd say rename yes but rebuild no, in order to keep the same digests >> and signatures. >> > >As mentioned earlier, that seems not to be possible. The metadata >(filename) and version information inside the package need to be in sync. >This how the python build tools and python ecosystem works. I'm not familiar with Python, but is it possible to have a command line option that adds the "-rc" suffix in the right places? IMO, there are two "audiences". One is the voters, and one is your customers. The customers should not be using the RC until after it is approved unless they are volunteering to be a voter. Voters are primarily supposed to examine a source artifact, but if you also release a "convenience binary" artifact, there are some examinations of that "binary" artifact required. For many projects this "convenience" artifact is the one that the vast majority of customers consume. AIUI, Python doesn't have binaries, but IMO, there is no requirement that this "convenience" artifact actually contains binaries. A "convenience" artifact is just supposed to be the source artifact processed by a build script since many of your customer may not have, or may not want to configure their machines to run whatever build script engine you choose for your project. Further, there is no requirement that I know of that voters must test the "convenience" artifact by actually running it. It just makes sense to do so in most cases. But if Python is interpreted source, you may be able to use this to your advantage. So, your source package should consist of the source and build script required to build this "customer"/"convenience" package, and the build script should allow a command line option to add the "-rc" suffix. Then voters would be instructed to download the source package, and to test it, build a "customer" package with the "-rc" suffix and test the results. And voters would also be instructed to download the "customer" package that doesn't have the -rc suffix. But in order to test it, they only have to diff that package against the "customer" package they built from the source package. It should be the same except for the metadata. We'll see if others can find a problem with this plan, but IMO, that would be good enough for me as an PMC voter. HTH, -Alex
