Compatibility between Kentico.Xperience.Lucene 6.0.0 and XbyK 29.0.0

[MilanLund]

Describe the bug I have updated all the nuget packages in my project:

• XbyK to 29.0.0
• Kentico.Xperience.Lucene to 6.0.0

After the update, I am experiencing a 500 Internal server error when I try I open the Development -> Search application in the Admin.

Also, when I attempt to delete a page using XbyK API, I am getting error that is referring to this Lucene integration.

So I am wondering whether the issue is on my end or on yours.

When I remove the Kentico.Xperience.Lucene from the project, things are working okay.

To Reproduce Steps to reproduce the behavior:

1. Login to Admin
2. Navigate to Development -> Search
3. See error

[seangwright]

@MilanLund yes, there are API breaking changes (mostly for .Internal namespace APIs) in Xperience v29.0.0.

Here's an example of one that has moved

We'll need to update the Xperience dependencies for this library, adjust the namespaces/APIs, and publish a new version which requires a minimum Xperience version of v29.0.0.

[MilanLund]

@seangwright Thank you for your prompt response. I noticed that the Kentico.Xperience.Lucene NuGet package was updated today, and the XbyK 29.0.0 was released yesterday. I'm curious about how it's possible for a new version of this package not to support the current core product version. Understanding your collaboration process would help me adapt and prevent similar issues in the future.

[seangwright]

@MilanLund I'm happy to give you some context 😄.

1. All of our integrations rely on the publicly published Xperience by Kentico NuGet packages. That means we can't begin working on updating them to support (or take advantage of features in) newer versions until those packages are published.
2. The Xperience by Kentico v29.0.0 NuGet packages were published yesterday at about 16:30 CEST yesterday, which is the end of the work day for folks in your (and our dev team's) area of the world.
3. We had already been working on v6.0.0 of Kentico.Xperience.Lucene to support deploying the administration separate from the website channel ASP.NET Core application and that work just happened to be finished today.
4. We realize some teams will already be updating their Xperience applications to the latest Refresh on the day of release, or the day after. While other teams won't apply updates for 2-4 weeks after a hotfix or Refresh.
5. But, our integrations ship separate from the product and will typically take a week or so to be updated if there are specific changes we to accommodate. The past several Refreshes have not had any breaking API changes, so no updates were required for integrations.
6. This repository is currently missing the release notes for v6.0.0, and that should be resolved to make it clear what was changed/supported in that version.
7. We already have this v29.0.0 support fix slated to be worked on and you should expect new packages that support >29.0.0 of Xperience to be released "soon".

I think it's great that you've already updated your project to v29.0.0! I hope more teams stay on top of updates as proactively as you. Most of the time, you wouldn't have any issues with this, but because of v29.0.0's (small) breaking API changes that just so happened to affect our search integrations, we need to catch up to the product (most of our other integrations work just fine with v29.0.0 without changes).

[MilanLund]

@seangwright Thank you for such a detailed answer. At this stage, it is not a serious issue for my project as I am in the early stages of development. However, I wanted to get some context, and you provided it to me, which is great. With so many changes to Kentico's new product in recent years, I am trying to catch up. The key takeaway for me is that the developers of the officially supported integrations do not have early access to future versions of the core product and therefore are reacting to already released packages. So I have to be really careful about updating the main product package. Taking into account the above, I am a bit afraid that if for any reason support is dropped or updates are significantly delayed for such an integration, it may block the project from being updated at all.

[seangwright]

So I have to be really careful about updating the main product package. Taking into account the above, I am a bit afraid that if for any reason support is dropped or updates are significantly delayed for such an integration, it may block the project from being updated at all.

I understand that perspective, but there's a couple things to consider:

1. Most Xperience Refreshes have 0 breaking changes and we'll often deprecate APIs for a period of time before removing them, giving teams (and our integrations) time to adapt.
2. The breaking changes for v29.0.0 were mostly with "pubternal" APIs - ones in .Internal namespaces but public C# access modifiers. While teams can use them, we don't make the same guarantees about support for them. But, this integration happened to use some of those for the sake of convenience. The dev team is continuously figuring out which APIs are ok to make "public" (in fact, most of the "pubternal" API changes in v29.0.0 went from .Internal to public namespaces).
3. We support our integrations with the same 7-day bugfix policy as the core product, so although we didn't have this integration updated immediately, it's a priority for it to support the latest version of the product.
4. We want it to be as easy as possible for you to adopt the latest versions of Xperience and our integrations, so most of the time, applying updates will be simple. Occasionally, there will be a few steps, code updates, or you'll need to wait a few days for a library to update.

[MilanLund]

Version 6.1.0 seems to resolve the issue. Thank you for a quick turnaround.