search

Azure / azure-sdk-tools

Tools repository leveraged by the Azure SDK team.
MIT License
114 stars 180 forks source link

Update design of tasks for the management plane sdk milestone #9186

Open maririos opened 1 month ago

maririos commented 1 month ago

Giving the new design https://github.com/Azure/azure-sdk-tools/issues/5659 we need to update the tasks that are part of the management plane SDK milestone.

Existing tasks:

For Greenfield services we need to add:

praveenkuttappan commented 1 month ago

We can still keep 3 main tasks.

  1. Prerequisites

    • Review product details
    • Select languages
    • Select target release month
    • Show Review spec details like, state, private or public repo and provide links to move private to public.
    • Show APEX related info.
    • Namespace tab a. We can ask a question if a package was already released. If yes then ask user to select the package name from our known package name list. b. If it's a brand new package or not found in the list then ask user for GitHub issue for approved namespace. Release planner should attempt to read the content of this GitHub issue and show approved names for each language. If release planner is not able to automatically query then we should inform the user and ask user to add the approved names manually in the text boxes.
    1. Generate SDKs
      • Show steps to generate SDK from TypeSpec
      • Show steps to generate samples
    2. Release SDK
      • Show SDK PR status
      • Show summary for release information, like package name, package version, api approval, namespace approval
      • Show change log verification status, (Show link to change log)
      • Show link to review of SDK reference doc
      • Show a button to release SDK. This should show an information popup stating that release planner will trigger the pipeline to queue a release. But user needs to approve the release of package once package is built.
maririos commented 1 month ago

If will be good to distinguish which steps will be per language and which are generic. For example, # 2 should be per language. Is the same true for # 3? If so, I also suggest that in # 3 if it is a new package, that here we link the package work item to the release plan