Update version to 8.2.4

[habbes]

Update library version to 8.2.4 and ODL version to 7.20.0

[gathogojr]

@habbes Shouldn't we be updating the library version as well?

[gathogojr]

@habbes See previous PR for updating ODL dependency https://github.com/OData/AspNetCoreOData/pull/922/files

[xuzhg]

Hold on, any changes needed in ASP.NET Core for ODL 7.19.0?
Actually, customer can update the ODL version at his side using 8.2.3, right?

[habbes]

Hold on, any changes needed in ASP.NET Core for ODL 7.19.0? Actually, customer can update the ODL version at his side using 8.2.3, right?

@xuzhg we added index-based access of path segments to ODataPath in ODL. This feature will allow us to speedup some path-based operations in AspNetCoreOData. So, we need to update the ODL version to get access to that feature.

[xuzhg]

Hold on, any changes needed in ASP.NET Core for ODL 7.19.0? Actually, customer can update the ODL version at his side using 8.2.3, right?

@xuzhg we added index-based access of path segments to ODataPath in ODL. This feature will allow us to speedup some path-based operations in AspNetCoreOData. So, we need to update the ODL version to get access to that feature.

if only the dependency updates (ODL), and no changes at (WebAPI), we don't need to release Web API. Since customer can update the dependency at his side (at any time). For customer, no matter what he should do is to update "one" package version.

1. If we release Web API, he must update the Web API version, And ODL version updates automatically.
2. if we don't release Web API, he want to use "new ODL feature/perf", he must update the ODL version. But He keeps his right to use "old ODL".

So, if no changes at Web API, I prefer to #2. That's my point.

[habbes]

Hold on, any changes needed in ASP.NET Core for ODL 7.19.0? Actually, customer can update the ODL version at his side using 8.2.3, right?

@xuzhg we added index-based access of path segments to ODataPath in ODL. This feature will allow us to speedup some path-based operations in AspNetCoreOData. So, we need to update the ODL version to get access to that feature.

if only the dependency updates (ODL), and no changes at (WebAPI), we don't need to release Web API. Since customer can update the dependency at his side (at any time). For customer, no matter what he should do is to update "one" package version.

1. If we release Web API, he must update the Web API version, And ODL version updates automatically.
2. if we don't release Web API, he want to use "new ODL feature/perf", he must update the ODL version. But He keeps his right to use "old ODL".

So, if no changes at Web API, I prefer to #2. That's my point.

As mentioned, there's some API changes in ODL 7 that we want to take advantage of in WebAPI 8. Specifically, we added indexed-based access for ODataPath, we can use this to refactor some methods in in WebAPI 8 to speed up performance (e.g. GetNavigationSource. That requires us to update the ODL version in WebAPI.

Besides that, we have a number of updates made to the library since the last release, ranging from bug fixes, new features and perf improvements, so we should still release a new version of WebAPI:

[xuzhg]

Hold on, any changes needed in ASP.NET Core for ODL 7.19.0? Actually, customer can update the ODL version at his side using 8.2.3, right?

@xuzhg we added index-based access of path segments to ODataPath in ODL. This feature will allow us to speedup some path-based operations in AspNetCoreOData. So, we need to update the ODL version to get access to that feature.

if only the dependency updates (ODL), and no changes at (WebAPI), we don't need to release Web API. Since customer can update the dependency at his side (at any time). For customer, no matter what he should do is to update "one" package version.

1. If we release Web API, he must update the Web API version, And ODL version updates automatically.
2. if we don't release Web API, he want to use "new ODL feature/perf", he must update the ODL version. But He keeps his right to use "old ODL".

So, if no changes at Web API, I prefer to #2. That's my point.

As mentioned, there's some API changes in ODL 7 that we want to take advantage of in WebAPI 8. Specifically, we added indexed-based access for ODataPath, we can use this to refactor some methods in in WebAPI 8 to speed up performance (e.g. GetNavigationSource. That requires us to update the ODL version in WebAPI.

Besides that, we have a number of updates made to the library since the last release, ranging from bug fixes, new features and perf improvements, so we should still release a new version of WebAPI:

Once we have other updates to release, let's move on.
Again, if only dependency updates, for example ODL improved the ODataPath, Customer can update the version at his side (Let customer to make a decision) then Our ASP.NET Core OData will automatically use the new improved 'ODataPath' logic. Right?

[habbes]

Once we have other updates to release, let's move on.

We do have other updates, here's the change log again: 8.2.3...main

Again, if only dependency updates, for example ODL improved the ODataPath, Customer can update the version at his side (Let customer to make a decision) then Our ASP.NET Core OData will automatically use the new improved 'ODataPath' logic. Right?

No, this does not apply to the current scenario. The difference here is we want to change the implementation of certain methods in WebAPI in order to get the improvements. But we cannot make those changes in WebAPI because they rely on new API changes introduced in ODL, so we need to update ODL in WebAPI first so that we can access the new API changes in WebAPI to improve the implementation. So this is not up to the customer, but up to us.

[xuzhg]

Once we have other updates to release, let's move on.

We do have other updates, here's the change log again: 8.2.3...main

Again, if only dependency updates, for example ODL improved the ODataPath, Customer can update the version at his side (Let customer to make a decision) then Our ASP.NET Core OData will automatically use the new improved 'ODataPath' logic. Right?

No, this does not apply to the current scenario. The difference here is we want to change the implementation of certain methods in WebAPI in order to get the improvements. But we cannot make those changes in WebAPI because they rely on new API changes introduced in ODL, so we need to update ODL in WebAPI first so that we can access the new API changes in WebAPI to improve the implementation. So this is not up to the customer, but up to us.

That's what I asked "Do we have any changes at Web API side?"

Supposed: The latest released Web API depends on ODL version 1.0.

And We have the following class and method in ODL:

public class A
{
      public void B() { }
}

Scenario 1

Without public API changes, only change the logic in B. We released a new ODL version 1.1 from version 1.0;

In this case, we don't need to release a new version of Web API. Since
a) If customer don't want to use the new logic in B(), he can keep using ODL v1.0 (without updating ODL)
b) If customer want to use the new logic in B(), he can update ODL version at his side manually. (be noted, updates once)

Scenario 2

You add a new API to implement the new logic for B(), We released a new ODL version 1.1 from version 1.0;

public class A
{
      public void B() { }

      public void B2() { }
}

In this case, if we want to let customer using B2(), we should CHANGE web API codes to call B2() method.
Then, we should release a new version of Web API. (be noted, customer updates once right?, but update the Web API version)

[habbes]

@xuzhg

Well understood.

My point was to clarify that:

• yes we do have changes made to Web API that we want to release (see changelog here 8.2.3...main)
• and yes, we do have public API changes made to ODL that we want to leverage in changes we want to make to WebAPI and so we need to update the ODL version web api as well.