Since I backported a bunch of stuff - there are only a handful of changes on branch_8_11 for 8.11.3 https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt:
Some general notes: * If it is a dependency upgrade - those are the hardest between main/branch_9x and branch_8_11 - the build tool changed and is completely different to how dependencies get upgraded. * Most simple bug fixes are relatively easy to backport - the biggest difference here is formatting changes since main/branch_9x has spotless formatting * Make sure not to break backwards compatibility or introduce issues on branch_8_11 since 8.11.3 would just be a bug fix release. * There is no guarantee that 8.11.3 will ever be released There are a bunch of old PRs - https://github.com/apache/lucene-solr/pulls - that most likely never go migrated to https://github.com/apache/solr Regarding https://issues.apache.org/jira/browse/SOLR-13219 - seems like something reasonable to backport and relatively self contained. Kevin Risden On Wed, Jan 18, 2023 at 12:00 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 1/18/23 09:25, Tomasz Elendt wrote: > > I have a question about backporting fixes to 8.11. As I understand there > are no new features being developed for 8.x but certain bug fixes are being > backported. At least I see a bunch of them done by Kevin Risden ([1]). My > question is: how does it work? How are the changes selected and applied? > The technical aspect is also interesting as Solr 8.x has a different > project structure. Are these changes applied manually? > > > > Would you folks agree on backporting > https://issues.apache.org/jira/browse/SOLR-13219 there? If it needs to be > done manually I can do it (I can prepare a new GitHub MR). > > > > The reason I'm interested in backporting it to 8.x is that we have an > issue with upgrading to Solr 9 (descried by my colleague in this thread > [2]) and we would like to avoid maintaining custom fork of 8.x ourselves. > > > > [1] like this one: https://github.com/apache/lucene-solr/pull/2670 > > [2] https://www.mail-archive.com/users@solr.apache.org/msg04714.html > > The bar is pretty high for backporting a fix to a branch in maintenance > mode, which is where 8.x is. > > Normally it only happens in these instances: > > 1) It fixes a vulnerability that has no workaround. > 2) The change is VERY trivial, so not likely to cause new problems, but > has big benefits for most users. > > The bar is slightly higher for triggering an actual new release on the > branch. Even if someone thinks the change is minor enough for > backporting, I don't think it is enough to trigger a new release. > > Without a new release, you're building Solr from source either way. If > it were me, I would maintain my own patched git repo and not expect that > upstream will include it. And I would keep a copy of the minimal patch > necessary so I could always create the patched repo from scratch. > > The problems you're having with 9.x are very strange. Would you be able > to get a thread dump from a problem server while trying a reload that > times out? Maybe we can figure out what's holding it up. Is it > happening on all cores for the collection or a subset that might consist > only of one core? > > Thanks, > Shawn > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
