Looks to me that solrbot is still the author of this
https://github.com/apache/solr/pull/2845/commits/3e0d943c22b7d7506356b98b39e9db8301d3
The cherry-pick script is not for windows, sorry... Maybe it works in WSL
Jan
> 5. nov. 2024 kl. 12:45 skrev Christos Malliaridis :
>
> So I went forwa
Thanks for the answers. I'm looking forward to the release then, to see the
process cycle complete. :)
I would love to use the cherry-pick.sh for also pushing to the branch, but
it fails on my machine / Windows when it tries to run the tests (probably
some gradlew / gradlew.bat issues). I didn't h
> One question that popped up recently (Jan can probably answer that):
>
> If I create a PR for backporting a cherry-picked commit that was previously
> completed with Solrbot, will the CHANGES file be updated by the bot? If not,
> I believe that I should update that in the PR myself, right?
A
>
>
> The topic about the Jetty blockers is probably worth its own thread, but
> to respond to Gus message: Jetty 10 may be a version we could work with,
> but it could mess up any ongoing work on updating Jetty.
Solr 9.x is already depending on Jetty 10. (and Solr uses javax classes
with it curr
Thanks for the responses David, this helps me to improve the documentation for
this process. I am proceeding with the dependency updates and so far it seems
most of the time to be straight forward, with a question popping up every now
and then. The only challenge so far has been the identificati
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
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
That's correct. One of the reasons I want to solve this is to get
everything ready for the version catalogs and potentially the Admin UI (as
it uses version catalogs as well). It's hard to keep track and update
versions that are not part of the versions.props, and we have quite a few
of them. I bel
I also agree with it being fine to just defer to the next release. They
can mostly be done all at once at that time. I read the dev-docs on this;
it's pretty clear.
The backports can be done in one fell swoop with
dev-tools/scripts/cherrypick.sh
Christos, as I understand it, you want to get thro
Hi,
We have a dev-doc for upgrading dependencies:
https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc
If something is unclear, please improve that doc.
Most SolrBot PRs are small and simple, and can be merged and backported in 2
minutes. By not adding CHANGES.txt entry we
Release time is fine in my opinion. If they are automated, I wasn't
recalling it. People running unreleased code can reasonably be expected to
do their own homework, and watch commits etc. However people deciding if
they will conduct an upgrade to a new release, or how to prepare for it
will want t
>From what I understood, entries in CHANGES.txt are automatically added
during release processes, so no actions are necessary from the developer's
point of view when merging the Solrbot PRs.
If I get you right Gus, you'd like to see at least these entries earlier,
and the changes should contain th
Changes in our dependencies ought to be tracked somewhere more digestible
than VCS. Users who use our test framework or have repositories containing
custom code intended to run inside of solr will care about changes in deps
for both solrj, and core, and whatever components. CHANGES.txt isn't great
I assume waiting any longer will not make much sense, so I am going forward and
start merging at least the "easy" dependency updates. I will also look into
documenting any experience / process at the end, so that others will have it
easier to address dependency updates in the future.
Keep an ey
I haven't either and I have the same doubts/questions. Hopefully there's a
developer docs page we can maintain on this and that which is linked to
from those PRs.
On Thu, Oct 24, 2024 at 10:15 AM Christos Malliaridis <
malliari...@apache.org> wrote:
> I got a few questions before interacting wit
I got a few questions before interacting with the Solrbot PRs, because I
haven't done that before.
- When are the CHANGES entries added, and when not? Is it just "if Solrbot
created the PR, then it will be added automatically during next release"?
- In case no additional actions are necessary, w
Lucene or jetty, or anything else that touches the jakarta vs javax package
switch mess any of those should be Jiras I think.
On the Jakarta/Javax topic: This is a MAJOR pain for one org I know,
because they have solr code in their repo, and use our test framework,
including the mini-cluster s
Indeed, please no JIRAs for these unless it's a bigger non-trivial upgrade
for some reason. Like for Lucene.
On Thu, Oct 17, 2024 at 5:46 PM Jan Høydahl wrote:
> I'm happy to just track the progress in each PR without additional JIRAs
> for each dependency. Perhaps an umbrella JIRA can be helpf
I'm happy to just track the progress in each PR without additional JIRAs for
each dependency. Perhaps an umbrella JIRA can be helpful though. Also, no need
for CHANGES entries for these, they get added to CHANGES during next release by
a script, as long as SolrBot is the committer. You can add y
The main blocker based on the PR comments seems to be the JDK version in
Solr that is too low to upgrade some of the dependencies. If Solr will use
JDK 21 in v10.0, it shouldn't be a problem updating these dependencies
before v10.
I could create a JIRA ticket with subtasks for each dependency upda
Hi,
There are now 36 open SolrBot PRs, some of which are several months old:
https://github.com/apache/solr/pulls/solrbot
Let's do a round of dependency upgrade merging to main + 9x prior to a 9.8
release.
Not a committer? You can still help e.g. by triaging the PRs that failed tests
and maki
21 matches
Mail list logo
