I would like to raise an exception to this, which is the Scala version/compiler.
I do think doing patch releases for this is warranted because we can easily make a rod on our own back by relying on old Scala scala versions and then when a security update is made we then end up creating a big bang update that spans multiple patch versions at which point we bring in a lot of changes at once. Also the Scala versions which we rely upon shouldn't have any big behaviour changes or if they do they are really inspected with a fine tooth comb. With Scala 2.12/2.13 is basically in maintenance mode anyways with typically only critical/security issues being merged. The only exception to this is changes that are made which make cross compiling/working with older JDK's easier (https://github.com/scala/scala/pull/10543 is an example of this). In the same vein Scala 3.3 is an LTS release which also provides similar guarantees. If we decide this isn't the case then we should revert https://github.com/apache/incubator-pekko/pull/1160/files tl;dr regarding patch releases I think that Scala compiler/version patch updates should be an exception but I agree that automatically doing patch updates for standard dependencies shouldn't be done unless it brings a security/critical bug fixes. On Wed, Feb 28, 2024 at 11:00 AM Arnout Engelen <enge...@apache.org> wrote: > On Wed, Feb 28, 2024 at 10:31 AM kerr <hepin1...@gmail.com> wrote: > > As we sometimes need to update dependencies on 1.0.x (maintenance) > branch, > > Can you motivate why we would 'need' this? I would prefer to keep > 1.0.x as stable as possible, and focus on updating and releasing 1.1.x > instead. Downstream projects can pull up dependencies in their own > builds. > > IMO changing anything on 1.0.x should be a rare, well-motivated > exception. In that case it doesn't seem worth automating those updates > with scala-steward and then disabling those automations again by > pinning versions. > > > Kind regards, > > Arnout > > > I suggest we do this with scala-steward, this will reduce some > maintenance > > burden. > > > > We can pin some dependencies on specified versions. > > > > background: https://github.com/apache/incubator-pekko/pull/1159 > > > > I'm +1 on this. > > > > 何品 > > > > -- > Arnout Engelen > ASF Security Response > PPMC member on Apache Pekko > Committer on NixOS > Independent Open Source consultant > > --------------------------------------------------------------------- > 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 Alexanderufer 3-7, 10117 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io