Actually, if we do 11 on 10x and follow 9.8 on jetty 10 with a quickish 9.9 that was just Jetty 11/SOLR-17503 backport that might be good for folks working with other libs that involve jetty and need a jakarta package based version that is not breaking back compat otherwise. Jetty 12 would then be free to show up one or two releases later in 10.x series.
On Sun, Oct 27, 2024 at 4:23 PM David Smiley <dsmi...@apache.org> wrote: > On Sun, Oct 27, 2024 at 3:47 PM Christos Malliaridis < > c.malliari...@gmail.com> wrote: > > > I have read the dev-docs multiple times before I started working on a few > > updates. One of the blockers some dependencies have is the upgrade to > Jetty > > 11 /12, which is a complex blocker. > > > Bummer. Also, I assume we wouldn't do a major Jetty upgrade in the 9.x > line. I'll let others speak if they think it'd be fine; I don't know > what's involved TBH. > > > > Another one was the JDK version, but > > that got sorted out with JDK 21 in main. Besides that, the overview of > > related dependencies and breaking changes is missing, which was probably > > one of the ways to contribute to the updates, even without write > > permissions. > > > > I don't understand. Write permissions to where? > > > > While working on the PRs, I faced various situations which I would like > to > > clarify and document at the end: > > - Should dependency upgrades of major versions be backported? > > > > Yes, in general. Do backports of whatever version unless you think it'd be > a big disturbing event in backwards compatibility of Solr. Even then, it's > negotiable; bring it up on this list. > > > > - What happens if a dependency has multiple licenses? We usually include > > only one, but which one do we choose? Is there a priority list? I found > an > > ASF policy (https://www.apache.org/legal/resolved.html) but it is not > very > > clear to me. > > > > That's in the FAQ there. Always choose a "Category A" license. Otherwise, > discuss it on this list first. > > > > - Is the notice file relevant for all licenses? Because we are missing > > quite a few changes / additions here (I'd like to address them all > together > > in a separate PR, now that we have quite a few differences with the > current > > versions) > > > > Also in that FAQ. I suppose it depends-then but including a NOTICE is safe > even if it may not strictly be necessary for some licenses. > > > > - Is it sufficient to pick license and notice file from Github > repositories > > (if they are available and the versions tagged)? I'd like to provide > > information in the documentation where to look for license and notice > > files, also for non-github projects. > > > > Yes, I think. But the most authoritative source would be in the > *distribution* (a tar.gz or zip) from wherever that thing is downloaded. > I'd simply do what you propose if you see the version tag and a file. > > > > - If an upgrade to a version is only planned for main (next major > release), > > like Jetty, should we still upgrade minor and patches in older versions? > > > > Yes. It'll be manual (no Renovate) but can follow our project > instructions. > > > > - I decided to upgrade some minor versions of dependencies on main, so > that > > they can be backported, and then make a major upgrade that is only > > applicable for main. This may be redundant, but there is no rule here, so > > input is appreciated. > > > > Yes; glad you did it this way. *In general* (not just dependency updates) > we do this... like say we want to remove something (for main) but in 9x > want to change something and perhaps deprecate it there. First we do the > change in main and backport to 9x and then do a main-only change. > Typically separate JIRAs too, as they have distinct fixVersion. We forget > to do the "main" change sometimes... which is why, prior to a major > release, we should review our "Deprecated" annotations for opportunities to > remove stuff. > > > > - Solrbot distinguishes between major and minor/patches and creates > > separate PRs (from what I saw). However, it looks like it does not work > for > > versions with suffixes. Is solrbot supposed to support semantic > versioning? > > > > ? Question for Jan. > > > > - Some dependencies introduce breaking changes (like JDK upgrades) in > minor > > versions. Solrbot will update the same PR as soon as a newer minor or > patch > > version is available. Should we upgrade these dependencies only in major > > and pick the latest non-breaking change / compatible version for > > backporting? error_prone_annotations is one example where it requires JDK > > 17 since v2.32.0. > > > > Yes. > > > > - It seems that Solrbot is not able to identify versions from plugins and > > JS libraries included in gradle files. Keeping track of them is hard, and > > should be better if we are able to switch to version catalogs. > > > > Cool. > > Thanks Christos! > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
