Establish Quality Bar for DPG/RLC libraries for all languages

annelo-msft commented 2 years ago

Issue

We would like to clarify the point at which architects can approve a DPG/RLC client library for GA.

Current Status

We currently agree that:

[x] Python will approve MVP libraries for GA. @lmazuel, @iscai-msft, could you confirm in the comments below?
[x] JS/TS will approve MVP libraries for GA. @joheredi, @xirzec, could you confirm in the comments below?
[ ] Java will approve MVP libraries for GA. @srnagar, @JonathanGiles, could you confirm in the comments below?
[ ] .NET architects will determine in the introductory arch board meeting how many convenience APIs are needed for the library to GA. They will review the library API once the requested convenience APIs have been implemented, and if the architects don't believe customers can be successful with the library, they will push out the GA date to accommodate adding further convenience. @KrzysztofCwalina, @tg-msft, could you confirm in the comments below?

Exit Criteria

We will close this issue once we have sign-off on the approval criteria for each language.

xirzec commented 2 years ago

I believe we are at a point where we would be comfortable GA'ing a RLC for a service that has had at least one successful beta release. I think the only issue we wanted to mitigate in the generator was around how we handle paths that contain a version number. I'll let @joheredi have the final word though. :)

annelo-msft commented 2 years ago

I think the only issue we wanted to mitigate in the generator was around how we handle paths that contain a version number.

@xirzec, do you know if you were planning to mitigate this in the generator (before GA of the RLC generator), or as a manual step for any library that encountered it, so it's not needed for your generator GA?

qiaozha commented 2 years ago

/ cc @qiaozha to get the updates of this.

joheredi commented 2 years ago

Yeah, the paths thing is not a GA blocker for the generator. It would be a GA blocker for a library with a version in the paths, the fix for those to unblock GA is to convert the path-based API version to change the swagger to represent it as a parametrized host.

As Jeff mentioned, we are comfortable GA'ing RLC codegen

annelo-msft commented 2 years ago

Sounds good, @joheredi! Can you also confirm that your plan is to GA generated libraries without any conveniences? (I think RLC doesn't have a convenience layer, so this may be an entirely moot point, just wanting to confirm.)

xirzec commented 2 years ago

Sounds good, @joheredi! Can you also confirm that your plan is to GA generated libraries without any conveniences? (I think RLC doesn't have a convenience layer, so this may be an entirely moot point, just wanting to confirm.)

The main conveniences we've been seeing value in are optional helper methods exported by the package. On a case-by-case basis we may include additional such helpers in an RLC

annelo-msft commented 2 years ago

Thanks, @xirzec! For the purposes of this issue, would you block GA of a library based on the need for these helpers?

joheredi commented 2 years ago

I don't think we would block release on helpers, new helpers would be additive and for convenience. An out of the box RLC should be able to perform all service operations

lmazuel commented 2 years ago

We are confident to GA Python DPG codegen as MVP (cc @johanste )

srnagar commented 2 years ago

For most libraries, Java DPG MVP codegen should suffice, but similar to .NET, we'd like to review that in the introductory arch board meeting and determine if there are no additional convenience APIs needed.

For e.g. if the champion scenario requires a different type of credential not generated by DPG or the user needs to make multiple REST API calls to perform one logical operation, we should consider adding convenience APIs to support these scenarios for GA.

annelo-msft commented 2 years ago

In an offline discussion with @KrzysztofCwalina, @lmazuel, @tg-msft, @Petermarcu, @mikekistler, @markweitzel and myself, we agreed that this is too nuanced to close prior to DPG v1.0 GA, but that we will not block DPG v1.0 on this decision.

As such, I am removing the blocking-release and DPG/RLC v1.0 labels, and reassigning to @markweitzel, who will work with this crew to find a solution that allows our team to be efficient with the DPG process. We understand that it is currently high cost.

github-actions[bot] commented 4 months ago

Hi @annelo-msft, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

github-actions[bot] commented 2 months ago

Hi @annelo-msft, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

Azure / azure-sdk