# apache/lucene-solr Is a Redirect: Where Lucene and Solr Live Now > The shared Lucene and Solr repository is now a pointer to two separate projects, with only 8.11.x bugfix work left on branch_8_11. Here is what that means before you clone anything. **apache/lucene-solr** — Apache Lucene and Solr open-source search software - Repository: https://github.com/apache/lucene-solr - Website: https://lucene.apache.org/ - Stars: 4,366 · Forks: 2,584 - Language: Unknown - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/apache-lucene-solr ## What apache/lucene-solr Still Is, and What It Stopped Being For years Lucene and Solr shipped from one tree: the library and the server, versioned together. The README at the top of this repository opens with a correction to that assumption. Solr has become a top-level Apache project, and main line development for both projects now happens in each project's own git repository. What remains here is a pointer, a licence, a PRs.md file and a branch. The practical consequence is narrow but real. If you arrived expecting to find current Lucene or Solr source, you will not find it in the main line of this tree. The audience for this repository is small: people who need the 8.11.x bugfix branch, and people who followed an old link and need to be told where to go. The README does not describe a product. It describes a move. ## The Split, the Two Repositories, and branch_8_11 The mechanism is a repository handoff, not a code change. Two git endpoints are named for ongoing work: apache/lucene for the library and apache/solr for the server. Bugfix development for 8.11.x releases stays on branch_8_11 in the shared repository, which is the only line of work the README says remains here. That gives three destinations instead of one. Current Lucene work goes to the Lucene repository. Current Solr work goes to the Solr repository. Backported 8.11.x fixes go to branch_8_11 in this one. Nothing in the README suggests the shared tree receives new features, and nothing suggests branch_8_11 will ever carry anything beyond 8.11.x bugfixes. Treat the branch as a maintenance lane with a fixed version number attached to it. For GitHub users the README is explicit that the gitbox repositories are not where pull requests go. It names two mirrors, github.com/apache/lucene and github.com/apache/solr, and says to clone the corresponding mirror and open pull requests against the main branch. Opening a pull request against a stale fork of the old combined tree is the failure mode this paragraph exists to prevent. ## Installing and Building from the Correct Repository This repository publishes no install instructions, no build command, no package name and no server configuration. The README gives repository URLs and nothing else, so the only honest first step is to clone the right tree. For current Lucene or Solr work, use the project repositories rather than this one. ```bash git clone https://gitbox.apache.org/repos/asf/lucene.git git clone https://gitbox.apache.org/repos/asf/solr.git ``` If you are using GitHub instead of gitbox, the README names the mirrors to clone and to target with pull requests. ```bash git clone https://github.com/apache/lucene git clone https://github.com/apache/solr ``` If your actual task is an 8.11.x bugfix, the README points at the shared repository and the branch that still carries that work. ```bash git clone https://gitbox.apache.org/repos/asf/lucene-solr.git cd lucene-solr git checkout branch_8_11 ``` After that checkout you are on the maintenance branch, not on a current release line. What you see next depends on the build files inside that branch, which the README does not document. Expect to read them yourself rather than follow a quickstart here. ## Where This Repository Is the Wrong Tool Anyone starting a new search project should not clone this repository. There is no main line development here, so a fresh checkout gives you either a pointer document or a branch frozen at the 8.11.x series. Building a new deployment on that branch means starting on a maintenance lane with no upstream feature path described in the README. The second wrong use is subtler: treating this tree as a single project when deciding between a library and a server. Lucene and Solr are separate repositories now, with separate main branches and separate pull request targets. A team that plans to embed search in a Java application and a team that plans to run a search server are heading to two different clones. Choosing one because the old combined repository is the link you have is a decision made by URL, not by requirement. The README is also silent on migration. It does not document how to move an existing checkout to the new repositories, how release artefacts are published, or what happens to the 8.11.x line after its last bugfix. If your plan depends on any of those, the README will not answer it. ## Lucene or Solr, and How That Differs from Elasticsearch The real alternative to this repository is not a competing product but the two repositories it now points at, and the choice between them is architectural. Lucene is the library: you embed it in a Java process and manage indexing, segments and search yourself. Solr is the server: it wraps that search capability behind an HTTP interface and runs as its own process, which is what most teams want when search is a service rather than a code path. Elasticsearch is the comparison people reach for, and the split clarifies it. Elasticsearch is a server product built on Lucene, the same way Solr is a server built on Lucene. Choosing Solr over Elasticsearch is choosing between two servers over a shared library lineage, not choosing between a library and a server. That distinction matters here because this repository used to blur it: one tree, one version number, library and server side by side. The split makes the layering visible, and it makes the library option easier to see as a real choice rather than an implementation detail of the server. ## Maintenance, Upgrades and the Apache-2.0 Licence The last push to this repository was on 2026-05-15, which is recent enough that the tree is not abandoned, but the README frames its remaining role as 8.11.x bugfixes on branch_8_11 rather than general development. Do not read a recent push date as evidence that new features land here. The README says main line development happens elsewhere, and that statement governs how you should plan upgrades. Upgrade cost follows from that. If you track branch_8_11, your upgrade path is bugfix releases within the 8.11.x series, and the README does not describe what comes after. If you want current work, your cost is a one-time move to the Lucene or Solr repository, plus whatever reconciliation your local patches need against a different tree. Plan for that move as a migration with its own review, not as a fetch. The licence is Apache-2.0, stated in the repository metadata and in the header block at the top of the README, which reproduces the standard Apache License, Version 2.0 notice and points to the full text. Apache-2.0 is permissive and includes an explicit patent grant, but this is a description of what the files say, not legal advice. If you redistribute or modify the code, read the LICENSE and NOTICE files in the repository you actually build from, since that is now one of three trees. ## Conclusion Adopt this repository only if you are maintaining or patching an 8.11.x deployment and need branch_8_11; everyone starting fresh should clone apache/lucene or apache/solr instead. Solr is now a top-level Apache project, so if you need a server with an HTTP API, the Solr repository is the one to read, and if you need a Java library to embed, read the Lucene repository. Verify first that the branch you intend to build still receives the fix you need, and check which repository your existing checkout actually points at before you open a pull request. ## FAQ ### Which is better: Lucene or Solr? They are different layers rather than competing options. Lucene is the search library you embed in a Java application, and Solr is a top-level Apache server project that main line development now happens in separately. ### Is Apache Lucene still used? The README states that main line development for Lucene is happening in its own git repository, apache/lucene, so the project continues outside this shared tree. This repository keeps only 8.11.x bugfix work on branch_8_11. ### What are the key differences between Apache Lucene and Solr? Lucene is the library, and Solr is a separate top-level Apache project with its own repository and main branch. The split means each has its own pull request target and its own development line. ### Is Solr still relevant? The README states that Solr has become a top-level Apache project and that main line development is happening in its own git repository. That repository, not this one, is where current Solr work lives. ## Sources - [apache/lucene-solr on GitHub](https://github.com/apache/lucene-solr) - [Issues](https://github.com/apache/lucene-solr/issues) - [License: Apache-2.0](https://github.com/apache/lucene-solr/blob/master/LICENSE) - [Project website](https://lucene.apache.org/) - [README](https://github.com/apache/lucene-solr/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-lucene-solr