The biggest issue with this strategy is that due to how maven works with resolvers expecting jars to be immutable, if we were to deploy a jar without an -RC and that jar happens to have an issue with it (and it gets voted down) then you are going to have to force every single person that resolved the artifact to manually delete those files in their local maven cache because even if you redeploy a new fixed version of that jar, it won't resolve on peoples machines.
I don't know of a principled way to solve this issue, maven has a fundamental exception that any non -SNAPSHOT jar shouldn't be changed, and by definition of having a voting process the contents of that jar can change. On Sun, Feb 23, 2025 at 9:25 PM PJ Fanning <fannin...@apache.org> wrote: > > Hi, > Apache Pekko is the only project that I am aware of that produces RC > jars (jars with RC in the version numbering) and then creates a 2nd > set of jars after the release vote passes. Most projects create jars > that have the prospective release number and just release them when > the vote passes. This takes up extra release manager effort, extra > review effort and leads to a longer release cycle. > The jars are left in the repository.apache.org staging area as opposed > to being released. > The only benefit as far as I can see of having the 2 stage jar build > is that people reviewing the jars might forget to clear the caches on > their machines. I still don't think this is worth the extra release > complication at this point. > > Does anyone have any opinions on this? I would like to try out the > change to the process in the upcoming pekko-projection release. > > Thanks, > PJ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
