Can someone expand on the downsides of having the Kotlin UI code in the main repo? Or the concrete benefits of separating it out?
I know there were some CI job failures around the time of the initial merge, but I haven't noticed it causing issues after that - did I miss some other discussion where those were covered? On Mon, Mar 17, 2025 at 2:47 PM Christos Malliaridis <c.malliari...@gmail.com> wrote: > > 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 > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
