Ensure that only "standard" or "experimental" APIs are exposed as dependencies.

[dawid-nowak]

Change is made so only one set of APIs is available as dependencies.
This avoids the situation where the application can import and use objectts from standard and experimental sets:

use gateway_api::apis::standard::gatewayclasses::GatewayClass;
use gateway_api::apis::experimental::gatewayclasses::GatewayClass;

Instead the code should look like :

use gateway_api::gatewayclasses::GatewayClass;

The user can switch between "standard" and "experimental" sets by setting feature "experimental" in their Cargo.

[shaneutt]

Thanks @dawid-nowak, appreciate you taking the time on this! 🙇

Looking it over, there's a nuance that I think is important here: This is change is focused on the presentation and convenience of giving you whichever release channel you require with a consistent import path.

One problem that we've found with Gateway API over the years is that some implementations will just use the Experimental channel, and go straight to production with it regardless of the fact that its labeled
"experimental". As such, I actually think making it more explicit to use the experimental APIs is an overall nuanced, but important thing.

What are your thoughts on this: Instead of swapping in experimental vs standard, we just bring the standard APIs upfront always because 99% of the time that's what people should/will be using. And then for experimental, they are simply not present unless you flag into the feature, and then you do have to import them specifically, and deliberately?

Let me know your thoughts? 🤔

[dawid-nowak]

From the longer-term perspective, I would expect that eventually "experimental" would be merged into the "standard" and it should disappear.

And if as you said projects just stick with "experimental" set to apis then potentially just exposing one set shouldn't make a difference (other than having to update the source code).

The biggest problem we would have is when projects mix "standard" and "experimental" APIs in one codebase...

I think the options are :

1. We keep the code as is but "experimental" is only enabled when the feature is enabled... Still, this allows "standard" and "experimental" to exist in one codebase.

use gateway_api::apis::standard::gatewayclasses::GatewayClass;
/// only if experimental apis are enabled via a feature flag
use gateway_api::apis::experimental::gatewayclasses::GatewayClass;

2. We move "gateway_api::apis::standard::*" to just gateway_api::* and keep experimental behind the feature flag... This would force the applications to use:

use gateway_api::gatewayclasses::GatewayClass;
/// only if experimental apis are enabled via a feature flag
use gateway_api::experimental::gatewayclasses::GatewayClass;

3. As currently implemented in the PR, the applications can't mix "standard" and "experimental" APIs and can only use :

/// there is only one import but this could be "experimental" or "standard" depending on a feature flag
use gateway_api::gatewayclasses::GatewayClass; 

I am equally happy with options 2 and 3 and slightly less happy with option 1 😄 .. but it is yours to decide.

[shaneutt]

Thanks for your thoughts! Option 2 looks right as it clearly indicates the APIs are experimental and makes it obvious in the usage. It also brings the standard APIs "up", which I think is good (though I prefer keeping them isolated with pub use standard::*; as you had before, to keep generated code very separate and "tucked away"). 👍

[shaneutt]

Also the DCO is failing, check here.