[enhancement required] The REST API spec breaking changes detection need to be enhanced in typespec conversion.
- Dominant language
- C#
- Stars
- 135
- Forks
- 260
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 143
Description
Take https://github.com/Azure/azure-rest-api-specs/pull/28023 for example. After the pull request being merged, service team approached to release SDKs. However, per manual review, there were multiple REST API breaking changes introduced after the team converted to using TypeSpec. Some of them were unintentional. More details can be found [here](https://github.com/Azure/autorest.java/issues/2803#issuecomment-2165654681). The issue is created to drive improvements of REST API spec breaking change detection prior to the program of [TypeSpec Brownfields Conversion](https://microsoft-my.sharepoint.com/:w:/r/personal/mattge_microsoft_com1/_layouts/15/Doc.aspx?sourcedoc=%7B57BAE71D-CCE9-446C-AD6D-B0A314B628C1%7D&file=TypeSpec%20Brownfields%20Conversion%20Specification.docx&action=default&mobileredirect=true&share=IQEd57pX6cxsRK1tsKMUtijBAUWaqqhv4lqD384_DZ1knC4) in execution.
Contributor guide
Research direction
Begin with Azure REST API Specs pull request 28023 and the linked autorest.java issue comment, then compare the manual breaking-change findings with what TypeSpec conversion detected. The issue does not name implementation files, tests, or an entry point; done criteria would need to define the missing detection cases and how they should be validated before the TypeSpec Brownfields Conversion program.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100