It is Java, but we have version references internally in all kinds of places. So, what happens is that the build creates the "expected final release", say "1.2.3" and sets all internal references to that. But the tarball will be -RCx, which is voted upon. And then, as Bertrand suggested, a rename of that tarball if the vote passes, is not a problem.
And as John points out, the release build tags "1.2.3" in git and we can (re)move that later if the vote fails. On Tue, Apr 25, 2017 at 5:18 PM, Bolke de Bruin <bdbr...@gmail.com> wrote: > Hi Niclas, > > Is this Java or Python? I can only find Java for Polygene. > > Furthermore, how do you manage this you repository? Do you have the > release already set in one of your files, e.g. something like this: > https://github.com/apache/incubator-airflow/blob/v1-8- > test/airflow/version.py <https://github.com/apache/ > incubator-airflow/blob/v1-8-test/airflow/version.py> > > The build system generates the metadata from there, which is used by the > package installers (e.g. pip). > > Cheers > Bolke > > > > On 25 Apr 2017, at 10:47, Niclas Hedhman <nic...@hedhman.org> wrote: > > > > 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 > > -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
