Odata dependency version

[Mhirji]

@commonsensesoftware like others I am running into issue #420 on the aspnetcore odata repo. This was apparently not an issue up until 8.0.5 was released so I tried to downgrade deom 8.0.10. It looks like aspnet-api-versioning has set 8.0.10 as the minimum version for its dependency on odata and I am wondering if there is a reason not to use the major version as you are accepting up till but not including 9. I know there was a bunch of refactoring after 8.0.4 which might be why, but just wanted to confirm.

[commonsensesoftware]

I'm not sure I fully understand what the issue is. You've cited a PR from 3.5 years ago that improved exploring the API version route parameter in the URL path. Furthermore, the code that was changed was for ASP.NET Web API, which is not related to ASP.NET Core nor OData (certainly not 8.0+). If you can articulate the issue in more detail, I'm sure I can provide some assistance.

The OData team's versioning policies and strategies are outside of my control or influence. Historically, there have been significant breaking changes between major version bumps. It has bit me many times and, therefore, I always clip off (e.g. exclude) the next major version out of an over abundance of caution. The 3rd segment of a semantic version is supposed to be a patch. If OData is properly following that, any 8.0.x is 8.0 with patch N. I've run into many different OData issues over the years and any patch version should be fixing known bugs/issues. Given how difficult it can be to distinguish between OData and API Versioning as the source of issues, I typically start with the most recent patch available to avoid possible standing OData issues. When available, I usually review the OData release notes as well.

The version numbers that you've outlined don't line up so I'm puzzled by that as well. Asp.Versioning.OData is the first package version to support OData 8.0. It references version 8.0.8 in preview.1. Since it is still preview, I saw there were OData updates, and the release notes indicates they are bug fixes, I bumped up to 8.0.10 in preview.3. If there is some other regression in OData, I would sure like to know about it. I'm not sure where 8.0.4 or 8.0.5 are being used or referenced.

[Mhirji]

I really was not clear, and for that I apologize. All the versions I mention are odata specific, not the asp.versioning packages. The question I have is that from what I see and understand, Asp.Versioning (when used with odata) has a min odata version on 8.0.10, but I need to roll odata back to 8.0.4 for now. As such, I am also trying to understand if asp.versioning really needs a min odata package of 8.0.10 or was that set as it was the latest. Hopefully that clarifies what I am trying to uncover.

[commonsensesoftware]

Gotcha. Thanks for clarifying. I kind of thought that might be what you were saying.

Things are still in preview so I'm not fully opposed to lowering the supported version. As I said, patches usually included fixes, so taking in fixes usually is not problematic. I can queue up this change for the next release, which will likely be release candidate. Before I make this decision and change direction, can you elaborate or link to the OData issue that requires this?

There's a chance that going backward could regress behavior in API Versioning. We'll cross that bridge if/when it happens, but that will certainly make things more hairy.

[Mhirji]

If it's a real pain, don't worry about it. Here is the issue, OData/AspNetCoreOData#420

[commonsensesoftware]

It shouldn't be much of a pain. I will look at going backward. I need to look at the release notes. If I can make it work with even 8.0.0, I'm not opposed to it. Moving the needle forward for specific fixes should be in your hands not mine. That would give you full control to go forward if and when you see fit. As long as all the core test scenarios work for API Versioning, that's good enough for me. Other specific OData fixes will have to be brought in by OData customers at their leisure.

It seems strange that a patch resulted in a regression that is considered a P2 enhancement. 🙄 🤷🏽‍♂️

I'll see if I can't get this flushed out this week.

[Mhirji]

Thanks! Regarding the regression, I get the feeling that the OData team does not really follow Major, Minor, Patch - there appears to have been a fair amount of refactoring which IMO should have resulted in a 8.1.0 release instead of a 8.0.5. Regarding it being classified as P2, yeah, its a bug that is affecting a number of people and given it was working before, should probably be a P1. As to why it is an 'enhancement', it appears, for some strange reason, that bugs = enhancements and enhancements = enhancements which personally I do not understand, but it is what it is.

As this is on your radar for the coming release (if it is possible to do without too much pain), I will close this issue.

Thanks again for all your work on this - and your patience with me and my issues !! :)

[commonsensesoftware]

Just FYI, I was able to get the full test suite to work going back to 8.0.2. This is when Microsoft.OData.ModelBuilder was updated to 1.0.7. That version [re]introduced support for Model-based Query Settings. Without that, some API Explorer features will not work as expected. The options are OData 8.0.0 with model builder 1.0.7 or just move OData up to 8.0.2. The second option seems simpler. I've updated the examples - only - with 8.0.10 so they can stay current. If you chose to only move up to 8.0.4 it should work for you. The change will go out in the next release.

[Mhirji]

Thanks for this @commonsensesoftware ! Do you know when you are planning to release the next version? Am happy to test it once you get it out :)

[commonsensesoftware]

Good question. I was thinking about how I wanted to handle that. I'm still waiting on code signing, but it's in progress. If I don't hear back by the end of the week, I'll follow up - again. Based on the stability, I was thinking of going to Release, but I can get behind doing a Release Candidate. Things are feature-complete and all of the issues have been fixed (but not necessarily published). I'll see if I can't get out a RC in the next day or two.

[Mhirji]

@commonsensesoftware, just a quick question, wondering if you have managed to make any progress on code signing?

[commonsensesoftware]

Sadly - no, but I do have an escalation path. I'll see where that goes. I'm completely blocked for updating the old packages. For the new packages, I can consider a unsigned versions until it's done.

[Mhirji]

Any news on the code signing? Given my level of frustration with this taking so long, I cannot imagine yours.

[commonsensesoftware]

@Mhirji sadly - no, but I'm getting much more vocal about it and spreading the word. I will try the escalation path. I don't know that will change much, but I can try. I will bring this issue up in the DNF meeting next week, but - frankly - the situation is ridiculous.