You will find Allesandro, and myself (Needham Software LLC) along with
many others here:
https://cwiki.apache.org/confluence/display/solr/Support
Feel free to reach out to any of us (gus *at* needhamsoftware dot com for
me)
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fanta
I suppose the only reservation is with respect to breaking back
compatibility with existing systems that never used it, or configured it
differently. However I would say that if we don't decide to make it
mandatory, those are bugs.
I will say that one of the things I discovered in the opensearch w
This was the original ticket/discussion over there when the issue first
came up in 2021 https://github.com/opensearch-project/OpenSearch/issues/1687
On Mon, Jun 30, 2025 at 4:47 PM Jan Høydahl wrote:
> Hi,
>
> Opensearch has released v3.0 with their new java agent capable of
> filtering network
Welcome :)
On Thu, May 1, 2025 at 1:14 PM Anshum Gupta wrote:
> Congratulations and welcome, Matthew!
>
> On Tue, Apr 29, 2025 at 10:35 AM Jason Gerlowski
> wrote:
> >
> > The Project Management Committee (PMC) for Apache Solr has invited
> > Matthew Biscocho to become a committer and we are pl
This sounds good to me because Dropwizard metrics is used by the Dropwizard
framework. Recent experiences where Dropwizard is used as an intermediary
layer and integration tests using our test framework have shown it's a path
to jar hell with Solr wanting one version and the Dropwizard based code
w
Wow. Nice catch. More reason we shouldn't be cramming everything into one
filter...
On Sun, Apr 13, 2025 at 2:13 AM dsmiley (via GitHub) wrote:
>
> dsmiley commented on PR #2876:
> URL: https://github.com/apache/solr/pull/2876#issuecomment-2799731147
>
>Finally I found the root cause of `Pac
I second the point about dates. Blog posts are (or at least should be)
always dated, and typically have a date based permalink for each post.
Ability to comment on the post is also normal (but of course only
meaningful if the post contains meaningful content in and of itself).
On Mon, Feb 3, 2025
In its current form it's more of a news feed than a blog. A blog should be
displaying the latest post by default with links/navigation to past posts.
Obviously, there's no hard rule there, but commonly the front page shows
the latest. This is also why ideally a blog post would be a full complete
us
>
> It makes sense for all our
> SolrRequest/SolrResponse implementations to be in the same package,
>
regardless of their provenance.
>
That sentiment sounds like "split packages" which is a practice that runs
contrary to the way the java module system works with respect to jars,
though I'm not s
Just noticed this discussion of Add-Opens manifest attribute. The docs on
this stuff are wonky, but all in the same way. They all fail to mention
Add-Opens as a manifest attribute. I think this is a thing that is in there
as an unadvertised feature. I suspect it's unadvertised because it rankles
th
Unless you think we shouldn't
> bother doing anything drastic/sweeping (possibly breaking users) if it's
> likely we don't even want it?
>
Yeah that's the core of it. We could wind up breaking things twice.
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
Welcome :)
On Mon, Dec 23, 2024 at 12:32 PM Christos Malliaridis <
c.malliari...@gmail.com> wrote:
> Welcome Pierre, looking forward to working with you. :)
>
> On Mon, Dec 9, 2024 at 10:23 AM Pierre Salagnac >
> wrote:
>
> > Thank you so much everyone!
> >
> > I am very excited to be invited to
With respect to the effect on JSON output I'm for that. A single
dimensional Array encoding a 2D array to communicate key/value pairs is
very contrary to any programmer's expectations (at least within this
century). So improving the rendering of our JSON at some point: definitely
+1 While we are at
Mentioned before at least here (with no clear decisions)
https://lists.apache.org/thread/vyqtxfxvkc1hy941yygnd7bkftm988bo
Other discussions I've seen on other projects:
https://github.com/opensearch-project/OpenSearch/issues/1687
https://github.com/pfirmstone/JGDMS/issues/126
On Fri, Dec 13, 202
There is definitely a need to allow users to transition away from javax. Am
traveling today but there is a blocker for 10x for that. Pls look it up...
(would but limited to phone at the moment)
On Tue, Dec 3, 2024, 11:21 AM gerlowskija (via GitHub)
wrote:
>
> gerlowskija commented on code in PR
>
>
> 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
I'm targeting 9.8 for SOLR-17151 if the rest of my life would ever stop
needing immediate attention.
On Tue, Oct 29, 2024 at 12:16 PM David Eric Pugh
wrote:
> Would it make more sense to do a 9.8? There are lots of CLI deprecation
> in 9.8 that would be nice to see the light of day before 10.
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
ionality issues, I see this as a crucial part of
> maintenance.
>
> I am trying to understand the reasons for these specific PRs becoming
> stale, so that we can take actions and improve this part. If anyone has any
> experiences or information please share them.
>
> On Sat, Oct 26,
That's far more polite than the linux edition, where it is much less
helpful and entirely fails to run:
Invalid Gradle JDK configuration found. Open Gradle Settings
On Sat, Oct 26, 2024 at 10:30 AM Christos Malliaridis <
malliari...@apache.org> wrote:
> So after a bit of trying around, I am faci
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
hmm when I try to change the project jdk to 21 in intellij I get
Cannot Save Settings
Content root
'/home/gus/projects/gus-asf/solr/fork/solr/solr/benchmark/src/test-files'
is defined for modules 'org.apache.solr.solr-root.solr.benchmark.test' and
'solr-root.solr.benchmark.test'. Two modules in a
ng IntelliJ just fine, and I can say
> IntelliJ compatibility was a critical concern and evaluation I did as a
> reviewer.
>
> On Thu, Oct 24, 2024 at 2:07 PM Gus Heck wrote:
>
> > I don't think we should have been pushing a change to a jdk not supported
> > by our bu
I don't think we should have been pushing a change to a jdk not supported
by our build tool?
My ide is now refusing to import with the big mismatch in my prior email if
gradle set to 17 or 19, but if it's set to 21 it just says "Invalid Gradle
JDK configuration found. Open Gradle Settings"
On Thu
I just updated (merging main into a branch I'm working on). Now Intellij
can't even reload gradle:
A problem occurred configuring root project 'solr-root'.
> Could not determine the dependencies of null.
> Could not resolve all task dependencies for configuration ':classpath'.
> Could not
Better phrasing actually: Servlets typically generate novel content.
On Wed, Oct 23, 2024 at 2:14 PM Gus Heck wrote:
> It's just decorating an existing resource... adding headers and
> filter/replace the content. Servlets typically generate their content.
>
> On Wed, Oct 23,
It's just decorating an existing resource... adding headers and
filter/replace the content. Servlets typically generate their content.
On Wed, Oct 23, 2024 at 11:51 AM David Smiley wrote:
> Why would that be a filter; doesn't a Servlet make sense?
>
> On Wed, Oct 23, 2024 a
at 9:30 AM Gus Heck wrote:
> As for next steps, I was planning on heading for creation of filters next,
> so that when a servlet is create it can just be configured with all the
> same filters. That way the old dispatch filter can continue to do it's
> thing without requiring all 3
.
On Wed, Oct 23, 2024 at 9:27 AM Gus Heck wrote:
> Absolutely one step at a time. We've seen in the past how an enormous
> change is just too hard to work back into the mainline, and I'd hate to put
> in the effort only to suffer that fate. Review is always welcome of cours
s
> for some obscure thing. FWIW I'd be happy to be a code reviewer. I tagged
> you for a review on something nearby the other day.
>
> On Tue, Oct 22, 2024 at 5:35 PM Gus Heck wrote:
>
> > Converting Solr to a servlet, or even a query servlet, an update servlet
> > and
Converting Solr to a servlet, or even a query servlet, an update servlet
and an admin servlet because those are really very separate operations has
been on my mind for a long time. The overlap among those operations is all
in things like authentication or tracing that should be reusable
ServletFilt
I was thinking about this recently too. I search our archives and the only
interesting email regarding hadoop was a response in which Dave Smiley
pointed out that the backend is pluggable and thus it could be used to
target S3... but probably if we want to support an S3 storage backend, this
should
Congratulations :) Welcome!
On Fri, Oct 18, 2024 at 8:21 PM Houston Putman wrote:
> Welcome Christos!
>
> - Houston
>
> On Fri, Oct 18, 2024 at 5:54 PM David Smiley wrote:
>
> > The Project Management Committee (PMC) for Apache Solr has invited
> Christos
> > Malliaridis to become a committer a
https://issues.apache.org/jira/browse/SOLR-17503
This is the stickiest bit in our lagging dependencies, but also one of the
most irritating from a user perspective IMHO.
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
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
+1 (binding)
On Tue, Oct 15, 2024 at 6:00 PM David Smiley wrote:
> +1
>
> On Tue, Oct 15, 2024 at 5:47 PM Anshum Gupta wrote:
>
> > +1 (binding)
> >
> > Anshum Gupta
> >
> >
> > On Tue, Oct 15, 2024 at 14:42 Houston Putman wrote:
> >
> > > Hey everyone,
> > >
> > > A little while back, I made
to us all -- do we want to create bespoke
> interfaces for lifecycle or maybe embrace something else? Like Jetty's or
> maybe HK2 (used by Jersey)? Not sure if this quite makes sense; I haven't
> thought through the practicalities.
>
> On Sat, Oct 12, 2024 at 11:07 PM Gus Heck
I was traveling, and most of my ongoing work is back on my desktop, so I
entertained myself on a flight by fiddling with an idea that's been
rattling around in the back of my head. It seems like it might be neat to
have a websocket interface to solr, but we definitely don't need it to live
in the m
hat does embedded
> ZK
> > > take, and decide it's okay. From my perspective, what scares me about
> > > resource consumption in future versions of Solr isn't ZK, it's vectors
> > and
> > > models anyway ;-).
> > >
> > > I
up quickly. Thanks for pointing it out.
> >
> > - Houston
> >
> > On Thu, Oct 3, 2024 at 12:22 PM Gus Heck wrote:
> >
> > > I went to the fucit jenkins reports site to check on the state of the
> > build
> > > after my recent commit to make
I went to the fucit jenkins reports site to check on the state of the build
after my recent commit to make sure all was well, but when I got there I
was greeted with several weeks of extremely frequent test failures and in
the last 2 weeks we seem to have gained several 100% failures (that clearly
In thinking about the testing for QueryLimits, I'm somewhat unsatisfied
because it seems like it would be ideal to be validating limit expirations
at various points in the request process but the current tests are all
thumbs, doing things like wasting CPU when query limits are checked which
can rel
gt;>>> Lucene Query objects being the end result. Also, they are nicely
> >> composable,
> >>>> and of course map almost 1:1 to ES JSON query dsl.
> >>>>
> >>>> So if we want to evolve SolrJ's ability to construct complex queries,
Also if expressed as xml the lucene classes can be sent to solr (not sure
if we have a tool to express them as xml however)
https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#xml-query-parser
On Tue, Aug 20, 2024 at 1:11 PM Mike Drob wrote:
> At the risk of sounding ignora
Our self serve sign up form is here:
https://selfserve.apache.org/jira-account.html
This will send an email to the PMC, and usually someone will approve it
fairly quickly. This approval process is intended to weed out folks who
think Jira is a good place to ask questions and folks who think it is
Ok PR is ready for RM approval: please approve and merge:
https://github.com/apache/solr/pull/2649
On Wed, Aug 14, 2024 at 4:29 PM Gus Heck wrote:
> https://issues.apache.org/jira/browse/SOLR-17298 needs 1 more merge (&
> backport), I will try to get it done tonight. Without th
> >
> > > > > > > ThreadPoolExecutor configuration affecting multiple features
> > albeit
> > > > one PR:
> > > > > > > * bad performance for backups of large collections
> > > > >
Yeah release wizard early... see my writeup here:
https://github.com/apache/solr/blob/main/dev-docs/releasing.adoc#step-1-run-the-release-wizard
(and feel free to add to it)
Also you'll want to peek at
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20resolution%20%3D%20Unres
https://issues.apache.org/jira/browse/SOLR-17298 needs 2 more merges...
one for https://github.com/apache/solr/pull/2588 and one more I will submit
soon with testing to verify the use of graphquery, rankquery and joinquery
with multi-threaded search (or prove and document that any of them should
b
On Mon, Aug 5, 2024 at 1:10 PM Eric Pugh
wrote:
> The lenient parsing thing is cool till you try to take the same json
> structure and use it in something else and it blows up.
^^^ This! 100% agree.
IIUC there were supposed to be memory advantages to noggit. I have not seen
this quantified, and the relevance of those advantages over current jackson
(vs libs available in the early 2000's) seems like a valid thing to
investigate.
Unfortunately, we have areas where we support json with duplicate
This is the dev list for people who are actively working on improving solr.
There are fewer people here and they are typically busier with active tasks
and have less time to help. This question would be better off posted on the
user's list. Additionally, you will need to give a lot more detail befo
e issue. Consider
> > that one just test noise; we should ignore it if it doesn't get fixed
> > soon.
> > https://issues.apache.org/jira/browse/SOLR-17368
> >
> > On Thu, Aug 1, 2024 at 8:34 AM Gus Heck wrote:
> > >
> > > Also looking at
> &
ere is
> something
> > > we could do with the generator task to mark those directories as
> generated
> > > sources that should be cleaned up (I could be totally wrong here)
> > >
> > > On Thu, Aug 1, 2024 at 8:49 AM Jason Gerlowski
> > > wrote:
> > >
Just noticed that that one is on main nevermind. (at least WRT the
release).
On Thu, Aug 1, 2024 at 8:33 AM Gus Heck wrote:
> Also looking at http://fucit.org/solr-jenkins-reports/failure-report.html
> we have a couple tests with high fail rates. This one seems to be
> reproducible
Also looking at http://fucit.org/solr-jenkins-reports/failure-report.html
we have a couple tests with high fail rates. This one seems to be
reproducible (reliably with seed, but also not hard to generate without)
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest > testNoAuth
FAILED
I keep having to waste time on errors like this:
> Task :solr:benchmark:compileJava
error: Annotation generator had thrown the exception.
javax.annotation.processing.FilerException: Attempt to recreate a file for
type
org.apache.solr.bench.search.jmh_generated.QueryResponseWriters_query_jmhTest
https://issues.apache.org/jira/browse/SOLR-17298 is more or less ready, but
would like it to at least have a few days sitting in main before I backport
it. Without it the multi-threaded search needs to be documented as not
working with cpuTimeAllowed.
On Thu, Jul 25, 2024 at 12:31 PM Anshum Gupta
There is currently such a step, but it's focused on looking for duplicate
entries. Editorial review at release time is difficult because Solr is so
big, and probably almost nobody stays on top of all the changes. Review at
PR/Checkin would seem to me to be the best route.
On Wed, Jul 24, 2024 at 2
I hadn't realized it wasn't marked for 9.7 but
https://issues.apache.org/jira/browse/SOLR-17298 was always intended as a
blocker as well.
On Thu, Jul 25, 2024 at 12:31 PM Anshum Gupta
wrote:
> Sure, I'll wait until the 30th. Thanks for letting me know.
>
> On Wed, Jul 24, 2024 at 9:39 PM Ishan C
I was just trying to tell someone that we publish a machine readable VEX
file and went to show them the link on our security page... but it came up
404..
https://solr.apache.org/solr.vex.json
-Gus
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
recall is already
> supported.
>
> On Tue, Jul 9, 2024 at 3:09 PM Gus Heck wrote:
> >
> > Also +1 ... "in the same repo and alongside" is how the last migration
> was
> > done IIRC. The big plus of this is as it's developed to a point of
> partial
> >
Also +1 ... "in the same repo and alongside" is how the last migration was
done IIRC. The big plus of this is as it's developed to a point of partial
utility you can put a link in the old UI to try out the new UI and get
feedback and make testing much easier.
One thing that might be nice if we can
hah, looks like David knows tricks I don't but list choice advice still
applies.
On Tue, Jul 9, 2024 at 2:56 PM Gus Heck wrote:
> Nope, but you can do that yourself by following instructions here:
> https://solr.apache.org/community.html
>
> Please think carefully about whic
Nope, but you can do that yourself by following instructions here:
https://solr.apache.org/community.html
Please think carefully about which list you really need to join. General
help and questions should go to the (larger) users list, whereas this
(smaller) dev list is for discussing changes to
To comment further, I think it would be good if we had query benchmarks
that tried to map directly to the queries benchmarked for lucene, against
the same data. This would give us a notion of which half of the equation
any slow down comes from (or speed up!)
On Fri, Jun 28, 2024 at 2:42 PM Gus
Yes. In fact I have an example in JesterJ of indexing the luceneutil
data... (but it's still in early stages, I think it's still against
_default schema, perhaps... (need to look again, haven't had time to work
on it recently)
https://github.com/nsoft/jesterj/tree/master/code/examples/wikidocs
On
I've fielded many questions on this from clients. Folks who have managed
databases expect to be able to upgrade the data serially across versions
and such, so these questions come up alot with organizations early in their
journey with search. Essentially, I tell them that it's a stop gap tool for
u
Welcome! Congratulations!
On Tue, May 21, 2024 at 4:56 AM Jan Høydahl wrote:
> Welcome on board Sanjay, thrilled to see the community grow. Thanks also
> for introducing yourself and for explaining Open Source to your Mom in such
> a simple way 😁
>
> Jan
>
> > 20. mai 2024 kl. 18:23 skrev David
+1 for SOLR-17275 blocking 9.6.1
On Tue, May 14, 2024 at 4:21 PM David Smiley wrote:
> Thanks for volunteering:
> https://issues.apache.org/jira/browse/SOLR-17275 is a blocker IMO.
> It's being looked at now.
>
> On Tue, May 14, 2024 at 3:38 PM Houston Putman wrote:
> >
> > Hey everyone,
> >
>
Only 22nd works for me, but I keep forgetting to show up so that's probably
only information that should be used for a tie-break.
On Fri, May 17, 2024 at 9:51 AM Alessandro Benedetti
wrote:
> (1) (3) and (4) for me!
> Thanks for the heads up Jason and thanks Raghavan for volunteering!
>
The thing about commit messages is they can't easily be cleaned up after
they are pushed... mistakes there are permanent.
On Fri, May 17, 2024 at 9:47 AM Alessandro Benedetti
wrote:
> I feel the same.
> It's error-prone, easy to forget and even easier to end up with conflicts.
>
> Sure, once the
Hi KrishnaVamsi,
Can you tell us a little bit more about how you are using it? You say you
are upgrading a client, but (as indicated by the package name)
org.apache.solr.servlet.SolrRequestParsers is a server side class, so it's
not quite clear why you are getting this from a client. Is this a pro
It detects documents that match a set of queries, so maybe "detector"?
On Thu, May 2, 2024 at 4:30 AM Jan Høydahl wrote:
> Alerting, while overloaded is probably the most precise name we could
> choose - documentation would help explain the scope.
> And if someone made an example project with a
I would be surprised if my refactor caused a change in this behavior.
All I did was move some initialization out into a
ServeletContextListener. If I did cause such a change, that would be
unintended.
>From the perspective of a web application container (which is what
Jetty is). There's no reason
Smiley, Michael Gibney, Paul McArthur, Jan Høydahl,
James Dyer, Eric Pugh, Andrey Bozhko, Andrzej Bialecki, Rahul Goswami,
Bruno Roustant, Jason Gerlowski, Sanjay Dutt, Vincent Primault,
Christine Poerschke, Gus Heck, Shawn Heisey, Vincenzo D'Amore, Yohann
Callea, Julien Pilourdault, Wei Wan
Ok it seems to be resolved now. I think I'll document this (and some other
high level info) in the releasing doc I've been working on in SOLR-17244 so
future release managers don't panic prematurely. Thx for the clarification.
On Sun, Apr 28, 2024 at 11:00 AM Gus Heck wrote:
>
Hmm if it's this:
https://ci-builds.apache.org/job/Solr/job/solr-reference-guide-official/
it's due soon.
On Sun, Apr 28, 2024 at 10:58 AM Gus Heck wrote:
> Is this done by a jenkins job, (or part of one)? Where can I figure out
> the schedule? I tried looking at http last-
ch exists but the release wizard step
> of updating the antora.yaml (after the release is done) has not been done
> (or is waiting on the nightly build to happen)
>
> - Houston
>
> On Sat, Apr 27, 2024 at 8:40 PM Gus Heck wrote:
>
> > I was about to send announcement
I was about to send announcement emails for 9.6 but then I discovered that
somehow the ref guide didn't seem to get the right version, and isn't quite
working... It lists a 9.6-beta version, which I had noted this 9.6-beta at
one point but I assumed that since I had never typed the word "beta"
anyw
I guess it's pretty easy to fix though. I'll do it.
On Sat, Apr 27, 2024 at 8:14 PM Gus Heck wrote:
> Are these clarifications critical? I have already passed the step where I
> copy the collaboration in the wiki into the site (I removed the jira
> numbers for that since th
Are these clarifications critical? I have already passed the step where I
copy the collaboration in the wiki into the site (I removed the jira
numbers for that since they weren't on prior versions)
-- Forwarded message -
From: David Smiley (Confluence)
Date: Sat, Apr 27, 2024 at 8
After some confusion, I think I have determined that the file in the html
site repo called guide.md is actually pointless now because of this commit:
https://github.com/apache/solr-site/commit/b035a8a695facaa9065341fdc2b40bfcecdc3350
Maybe it should be emptied out or even removed. There's a vague
It's been >72h since the vote was initiated and the result is:
+1 7 (6 binding)
0 0
-1 0
This vote has PASSED
I agree with Chris's assessment, and so I'm not tallying the vote...
On Fri, Apr 26, 2024 at 1:49 PM Chris Hostetter
wrote:
>
> : Reproduced on my machine too, but it's a timeAllowed test that relies on
> : timeAllowed=0 which is arguably a degenerate setting, OTOH it did start
> : failing in ma
vestigation)
so if I close it without reversing my vote the release passes.
What's the feeling from the rest of the community on the best way to
proceed?
On Fri, Apr 26, 2024 at 10:18 AM Gus Heck wrote:
> Reproduced on my machine too, but it's a timeAllowed test that relies on
> ti
Reproduced on my machine too, but it's a timeAllowed test that relies on
timeAllowed=0 which is arguably a degenerate setting, OTOH it did start
failing in march, and timeAllowed/Limits are something touched in this
release.
https://ge.apache.org/scans/tests?search.relativeStartTime=P90D&search.ro
you to those who contributed to this release: David Smiley,
> Gus Heck, Christine Poerschke
>
> (Of course the actual list for 9.6 is much longer). Back when I
> started this thread, I wrote a script that I put up in a Gist:
> https://gist.github.com/dsmiley/876f37089778d7d8abb4
Alejandro Arrieta
>
> On Tue, Apr 23, 2024 at 4:28 PM Gus Heck wrote:
>
> > As a side note the clamav process appears to have been a red herring. For
> > me the command succeeds ~40-50% of the time (after adding --no-cache) no
> > idea why.
> >
> > On T
As a side note the clamav process appears to have been a red herring. For
me the command succeeds ~40-50% of the time (after adding --no-cache) no
idea why.
On Tue, Apr 23, 2024 at 9:23 AM Gus Heck wrote:
> This could be an issue with anti-virus software or gpg-agent... I got the
> same
140BC45803B03F7F: public key "Patrick Gustav Heck (CODE SIGNING
> KEY) " imported
> > gpg: can't connect to the agent: IPC connect call failed
> > gpg: Total number processed: 1
> > gpg: imported: 1
> >
>
>
Please vote for release candidate 1 for Solr 9.6.0
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/solr/solr-9.6.0-RC1-rev-f8e5a93c11267e13b7b43005a428bfb910ac6e57
You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/smokeTestRelease.
Initial release notes have been drafted here, please flesh out, refine,
copy edit as needed.
https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote9_6_0
-Gus
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
NOTICE:
Branch branch_9_6 was cut a week ago, with agreement of an additional week
for further changes. That week has passed and we should now be in a
standard feature freeze. Versions updated to 9.7 on the stable branch.
Please observe the normal rules:
* No new features may be committed to the
with
>
> dev-tools/scripts/releaseWizard.py --init
>
> Hope that helps. The error message should probably mention that release
> x.y.z is already in progress and the --init option.
>
> Jan
>
> > 22. apr. 2024 kl. 15:28 skrev Gus Heck :
> >
> > Except it qui
Welcome Jason :) and thanks again to David
On Mon, Apr 22, 2024 at 10:13 AM Jason Gerlowski
wrote:
> Thanks all for the kind words, and thanks especially to David for
> serving this past year!
>
> On Fri, Apr 19, 2024 at 9:00 AM Anshum Gupta
> wrote:
> >
> > Thank you for your effort, David!
>
The move to the latest is of course usually a good idea, but sometimes
beyond risk tolerance for some customers. If the fixes are already
committed and will be in future releases, a one-off custom build that is
effectively but not officially 9.1.2 might be worth considering. Don't give
it that numb
this design back then. I think the
> reason was that the wizard code and steps could actually differ between
> versions, since e.g. main branch may include new features that demand
> special treatment during release. One such is the JDK version requirement
> that is checked at start.
it clone inside .solr-releases, so you may have
> to run a git fetch on that clone.
>
> Feel free to ask for other questions. There are many former RMs here. And
> also appreciated with PRs for the wizard itself should ther be bugs or
> unclear documentation.
>
> Jan
>
> > 21.
It seems in the last couple of point releases we've tagged stuff as 9.4 and
9.5 in Jira, but this time around 9.6.0 has been used in 59 out of 61
issues...
I'm guessing, we want to bulk change all of that to 9.6 to match prior
releases...
LMK if this doesn't sound right, or I missed the memo on a
1 - 100 of 309 matches
Mail list logo
