I'm cancelling this vote. I will create an RC3 later today.
On Thu, 29 Jun 2023 at 13:17, Chesnay Schepler <[email protected]> wrote: > > > This means with the projects I mentioned earlier, when a vote passes for a > final RC the > release manager renames the source package and they also rebuild the > convenience package > without asking for an additional vote. > > Since you mentioned the Flink project earlier: > > We neither rename any file we voted on nor rebuild anything after the vote > has passed. > We copy the source release files as-is from one directory (that has an rc > suffix) to another directory without a suffix. > We do the same for our convenience binaries. > Jars from the staging area are released as-is, without a suffix. > > In fact we don't encode the RC suffix into any artifact at any point. > > On 2023/06/29 10:22:24 Matthew Benedict de Detrich wrote: > > > Not sure, if that's really a compromise, as the changed binary > > artifacts can have different semantics with the changed versions > > numbers. So, while we could avoid reevaluating the source release > > which should (enforced to) be identical between RC and final release, > > the binaries need to be reevaluated rather more strictly than in other > > projects that 1) don't change semantics with version numbers and 2) > > don't need to be rebuilt for the final release. > > > > Yes I am aware of this (it's the same reason why I said earlier that you > > cannot just rename the binary i.e. convenience packages). > > > > The main justification for this compromise is that while its true that > > the binary artifacts change when versions change, if you assume > > good faith from the release manager when they create the final release > > package they should only be changing the version and nothing else as stated > > in this > > step > > https://github.com/apache/incubator-pekko-site/wiki/Pekko-Release-Process#deploy-the-jars-to-apache-maven-repository-staging > > . > > For this reason it was deemed that creating another entire voting round was > > considered > > excessive because the source package would be exactly the same (if the > > final vote for an RC > > is accepted then no extra changes should land) hence why the sunset period > > of 3 > > business days was added. > > > > In other words people can check the final release binary artifacts in the > > staging > > repository and if they see an issue then they can mention it and we can > > drop the > > artifact and rebuild. This is also mirroring what other upstream projects > > like > > Kafka or Flink do (I verified this by both checking/being part of the > > release process > > and also asking PMC's) > > > > > I‘m not aware of any project that makes changes to what was voted on > > after the vote, as IMO, that would make the vote mostly meaningless. Which > > projects are doing this? Some projects might rebuild binary releases from > > the voted-on source release, but even that is quite unusual. Most projects > > either publish the binaries separately as a convenience or vote on the > > source and binary releases simultaneously. > > > > > I would be wary of copying what other TLPs do, as you may not know the > > history or reasoning behind why they do it. Most ASF “rules” are > > guidelines, and if there is a good reason for a project to do something > > another way, it may be able to be done that way, but you would need to > > discuss that with the IPMC first. > > > > > Source releases are published using a svn mv command from the voted-on > > released artefacts, so you can’t change them other than what is are named. > > Changing them would mean the votes on signatures and hashes are invalid. > > Some projects use the same artefact name and just put them in directories > > called RC1, RC2 etc > > > > Just to clarify, I was talking about binary i.e. convenience packages, not > > source packages. > > Renaming a source package with Pekko is not an issue because the version is > > not > > hardcoded inside of the source package, it's dynamically set when you > > build/compile the source. > > This means with the projects I mentioned earlier, when a vote passes for a > > final RC the > > release manager renames the source package and they also rebuild the > > convenience package > > without asking for an additional vote. As you pointed out the source > > package does not need an > > extra vote as long as you just rename it without modifying the contents. > > > > > In that case you should use the real version number and just rename the > > artefacts -RC1, -RC2 etc as needed when voting on them. > > > > As stated earlier for source packages this isn't an issue, in fact > > it's already been solved (as stated earlier), it's with binary builds that > > it's a problem. > > > > On Thu, Jun 29, 2023 at 11:25 AM Johannes Rudolph < > > [email protected]> wrote: > > > > > On Thu, Jun 29, 2023 at 10:24 AM Matthew Benedict de Detrich > > > <[email protected]> wrote: > > > > This is why we came up with the "Leave the 1.0.0 artifacts up for 3 > > > > business days so that the community can verify that they match the > > > > latest > > > > successfully voted RC artifact" rule in > > > > > > > https://github.com/apache/incubator-pekko-site/wiki/Pekko-Release-Process#build-the-release > > > > as a compromise between how other major TLP projects work and not > > > > needing > > > > what is seen as an unnuccessary vote. > > > > > > Not sure, if that's really a compromise, as the changed binary > > > artifacts can have different semantics with the changed versions > > > numbers. So, while we could avoid reevaluating the source release > > > which should (enforced to) be identical between RC and final release, > > > the binaries need to be reevaluated rather more strictly than in other > > > projects that 1) don't change semantics with version numbers and 2) > > > don't need to be rebuilt for the final release. > > > > > > In particular, there's logic in pekko modules to restrict which module > > > versions are allowed to be combined at runtime. Currently, the rule is > > > a simple equality check that validates that all pekko core modules are > > > at the same version at runtime, so the risk is currently low to get it > > > wrong. > > > > > > The other risk regarding binaries is the general risk that the > > > required manual release process can go differently (wrong) between RC > > > and final release. > > > > > > Not sure if we can or should skip the vote, but we should definitely > > > not skip the evaluation of the final binaries. > > > > > > Johannes > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
