> 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. Thanks for the clarification, just to confirm this means that when you are voting on RC's the actual maven jars (i.e. convenience package) which I presume is deployed to ASF maven staging repository it does not have the RC suffix in the version? If so, how do you handle caching issues when users download the staging artifacts? Maven as part of dependency resolution assumes that non SNAPSHOT suffix jars are immutable and if you happen to be creating release candidate jars without the RC suffix in the version and you have multiple release candidates (for the same version that you are trying to release) then it breaks this assumption which can cause issues when it comes to caching (amongst other things). This is the reason why, at least for binary jars we are using RC in the version suffix. On Thu, Jun 29, 2023 at 2:17 PM Chesnay Schepler <ches...@apache.org> 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 < > > 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 > > -- 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
