> 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]
