We have a similar issue in Polygene, but the internal version is simply the expected version, say 1.2.3 and the RC has the different file name. No packagers will ever get the -RC named artifact and no confusion is among community members as they are aware of this. IF the RC passes, then the rename can happen. IF the RC doesn't happen, you can rebuild with new content and same internal version.
Cheers Niclas On Tue, Apr 25, 2017 at 4:43 PM, 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. > > - Bolke. > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
