Hi Cassandra. Sure, We can create a job on ASF Jenkins that is only manually
triggered.
It builds the maven artifacts into a local file system repo. As post build job
we publish the output folder on nighties repo like the ref guide.
The version number is passed as -DreleaseVersion system propert
Thanks for raising this. I'm not aware of WIP.
I think we can create a "SolrVersion" class, copying the approach Lucene
has taken? The SolrVersion can have access to the Lucene Version, since
Solr is dependent on Lucene.
Another related issue is that I think Solr should do away with the schema
It could be a manual process if that’s what you think is easiest and it could
still be on nightlies. It’s just a curl command to push something up:
https://nightlies.apache.org/authoring.html. If it is a manual process, I think
it would be better for it to be hosted in a place any of us could ac
The Solr PMC is pleased to announce the release of the Apache Solr Operator
v0.3.0.
The Apache Solr Operator is a safe and easy way of managing a Solr
ecosystem in Kubernetes.
This release contains numerous bug fixes, optimizations, and improvements,
some of which are highlighted below. The relea
I asked on the Lucene dev list about possible use of the Nightlies server.
We don't want to pollute nightlies on a regular basis (I think); this would
be an on-demand thing. As such, I'm not sure a CI server is the best way
to approach this vs a manual script publishing to an ASF personal Home
spa
Hi,
So far Solr has always had the same version as Lucene, so we have tons of
places in our code that checks the org.apache.lucene.util.Version class.
Going forward we'll soon end up in a situation where we e.g. release Solr x on
top of Lucene y.
Some places we ne need to continue checking on L
