Even if the build & language were well matched, a separate repo with
separate releases might be best anyway as it will eventually be
independently deployable from Solr as an option.
On the other hand, a separate repo may run a risk of getting stale relative
to Solr; its tests not passing if Solr i
Our new UI module has unique/interesting build requirements. And it's
another language as well. Instead of incorporating it directly into our
codebase, should it instead be another repo like
https://github.com/apache/solr-ui (doesn't exist yet), as we already have
the solr-operator (written in Go
I'm adding https://github.com/apache/solr-operator/issues/761 as a blocker,
but there is an easy fix! https://github.com/apache/solr-operator/pull/766
- Houston
On Thu, Mar 13, 2025 at 10:43 AM Jason Gerlowski
wrote:
> In terms of outstanding blockers I'd like to get a fix in place for
> https:
In terms of outstanding blockers I'd like to get a fix in place for
https://github.com/apache/solr-operator/issues/759 before we build an
RC. It looks like a small syntax error in the bash script run by our
'setup-zk' container. Hoping I can have a fix in the next day or so.
I'm tempted to list
Alright, not hearing any objections so I'll proceed with a 0.9.1 release!
The usual spiel/reminder about our release branch conventions:
I am now preparing for a Solr Operator bugfix release from branch release-0.9
Please observe the normal rules for committing to this branch:
* Before committi
