> 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 < > johannes.rudo...@gmail.com> wrote: > > > On Thu, Jun 29, 2023 at 10:24 AM Matthew Benedict de Detrich > > <matthew.dedetr...@aiven.io.invalid> 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: dev-unsubscr...@pekko.apache.org > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > -- > > 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:* matthew.dedetr...@aiven.io > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
