Hi Bolke, I dont believe a non-release version would be ever published publicly outside of dist.apache.org/dev/.
I am not sure what a good answer is. One thing I can think of is that given that vote is really only for the source bits and as long as the source tarball/release commit hash is not being modified after the vote completes and the community (PMC) trusts the release manager to publish the correctly modified convenience artifacts (binaries), it should be okay. But this is something the community needs to agree/resolve together. -- Hitesh On Sun, Apr 23, 2017 at 12:17 AM, Bolke de Bruin <[email protected]> wrote: > > > Sent from my iPhone > > > On 23 Apr 2017, at 03:46, Hitesh Shah <[email protected]> wrote: > > > > On Fri, Apr 21, 2017 at 8:19 AM, Chris Riccomini <[email protected]> > > wrote: > > > >> > >>> Version in pkg-info has an rc0 notation. It should just be > >> 1.8.1-incubating. > >> > >> This is a bit tricky to do with Python builds. I don't really want to > keep > >> building RCs with the exact same version number. We bake these RCs in > real > >> environments, so we need to version them with something that > distinguishes > >> one from another. Once we set the version, that propagates into the > >> pkg-info. The plan is to rebuild the final RC that passes without the rc > >> notation, so the release doesn't contain it. > >> > >> > > I understand the rationale but this means that there is a potential > > difference in what is being voted upon and what is eventually being > > published as a release. > > > > thanks > > -- Hitesh > > Hi Hitesh, > > This is a chicken and egg problem. If we put a non release 1.8.1 online > users will download and install it. An update to this package will not > trigger an upgrade on the user's side and it is hard to recognize (one will > need to compare signature). It puts them at risk. > > Do you know how other python projects solved this? I will reach out to the > libcloud guys and ask them how they did it (also python). > > Bolke
