Re: gradle reboot
Le 29/11/2024 à 12:40, sre4ever@free.fr a écrit :
Or maybe we can keep all of them in experimental for a while, and
duplicate only those that prove (or are suspected eventually, after
discussing that) to be problematic? I would rather keep things as
straightforward as possible with the dependencies, gradle has a lot of
dependencies but several of them only have very few reverse-dependencies
other than gradle and sometimes kotlin.
I'm not a big fan of potentially long lived experimental packages as it
makes updates in sid more complicated. For example let's say the package
foo has the version 1.0 in sid/testing and the version 3.0 in
experimental, the upstream and pristine-tar branch on salsa are updated
to the 3.0 release. If I want to update the sid package to 2.0, I can't
import the release without rebasing/reimporting the experimental 3.0
release on these branches.
By the way, any opinion about making that new gradle a "gradle8" package
that provides "gradle"? My feeling is that maintaining up to 3 major
versions of Gradle is probably going to be necessary, given the breaking
changes with every major release (and sometimes in between) and what's
already announced for future releases.
I have no objection to upload even 10 versions of Gradle if that's part
of a plan to get to the latest release and eventually drop the temporary
packages. We can keep the extra releases in sid only to avoid raising
concerns from the release and security teams.
Emmanuel Bourg
Reply to: