I was considering this from the beginning, and I was not aware of the whole stack we were using for building Solr. I thought that the GitHub workflows would be sufficient to guarantee at least the build processes to succeed in all our CI/CD environments, but I was wrong.
Since the UI is generating files that are simply hosted / executed, it does not need all the stack we currently have for Solr. Therefore, it does make sense to use a separate repository. The risk of it getting stale is high indeed, but I believe it is still easier to discontinue it if it becomes stale before the full replacement of the current UI. If we decide to move it to a separate project, we would have to guarantee somehow the replacement of the current UI once the new UI covers most (if not all) features currently present. This was one of the main discussions and reasons we tried to integrate it in the current repository. If we can maintain its connection to the Solr project, like with the operator, I believe it is an acceptable trade-off to move it out. I am personally not a fan of git submodules, but I like the idea of including it as a dependency (not sure what options we would have here). I also have from the beginning the wish of a separate "release cycle" for the development phase of the new UI, probably realized with a combination of nightly builds and actual releases in the ASF way, to speed up the early phase and gather user feedback. I believe this would be much easier with a separate repository as well. And about breaking changes in Solr, the new UI will focus on the v2 API of Solr. Since both are experimental, breaking compatibility is acceptable I think. The UI's 1.0 release would also depend on the v2 API of Solr. On Thu, Mar 13, 2025 at 9:03 PM David Smiley <dsmi...@apache.org> wrote: > 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 is updated. To mitigate that, I > could imagine a dedicated Jenkins job. > > On Thu, Mar 13, 2025 at 2:54 PM David Smiley <dsmi...@apache.org> wrote: > > > 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) and solr-sandbox? I didn't think of > this > > before because we decided we want Solr to ship with a UI but that doesn't > > actually mean we need to build that UI within Solr. It could be a > > dependency. > > > > We might even consider "git submodule" so a developer can opt-in to > > include it if they want to work on it; otherwise the latest release is > > included as a dependency. It's not clear we'd need to bother integrating > > the gradle builds. > > > > I'm not certain if another repo forces an independent ASF release process > > (e.g. voted on, etc.), as is for the Solr Operator. Wouldn't be a bad > > thing, anyhow. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > >
