> The maven jars do not have an RC suffix in the version, correct. > We don't account for the caching problem at all. > We don't advertise RC artifacts to users to being with; devs wanting to test releases have to handle this on their own. > In practice I don't think we do a lot of testing with the jars; a fair amount is covered by our tests.
That explains everything then. In Pekko's case specifically since its a library one of the primary way of testing Pekko in the release process would involve users resolving RC artifacts via maven/sbt/gradle in their existing projects (this is in addition to running tests the normal way) so excluding the RC suffix in release candidate jars would create a lot of confusion/chaos in this regard. On Thu, Jun 29, 2023 at 3:55 PM Chesnay Schepler <[email protected]> wrote: > The maven jars do not have an RC suffix in the version, correct. > > We don't account for the caching problem at all. > We don't advertise RC artifacts to users to being with; devs wanting to > test releases have to handle this on their own. > In practice I don't think we do a lot of testing with the jars; a fair > amount is covered by our tests. > > On 2023/06/29 13:28:33 Matthew Benedict de Detrich wrote: > > > 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 <[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] > > > > > > > > > > -- > > > > 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] > > -- 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]
