v1.4.0 Endgame

[tbombach]

Note: Public releases are always even numbered (e.g. 1.2.0). Nightly releases are odd numbered (1.3.0), which the build system handles automatically. When you release, make sure to bump the version to the ne t even number. Once that is merged, nightly releases will start releasing with the next odd number.

Checklist

1. Version bump

• Create a release branch from version of master intended to be released. Name it "Rel#.#.#", e : Rel1.2.0
• Update version in package.json in the release branch
• Update CHANGELOG.md with changes made in the release branch.
• Submit the above edits as a PR and have it reviewed.
• Run through the Testing Checklist below to find any potential regressions using the latest pre-release version published to the marketplace

2. Testing Checklist

YAML Submissions

For each of these items, search for the command Azure ML: Create <resource> that corresponds with each item. After editing properties, submit by right-clicking the editor and choosing the conte t menu item Azure ML: Execute YAML.

Make sure that you have selected a default Azure ML Workspace. You may need to setup the Azure CLI if you haven't already: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-configure-cli?view=azureml-api-2&tabs=public

It can be helpful to use this resource folder: [Resource folder](https://microsoft-my.sharepoint.com/:u:/p/leoyao/EUF9qpImyPpOhcv0A-5tY_YB_cTobKouUN15 hpYyaMgAw?e=0itZvB ) that has data files, training scripts etc.

• Create workspace
• Create experiment
• Create environment
• Create aml cluster
• Create aml compute instance
• Create a new version of a dataset (data asset). This can be done by submitting a data asset yaml with same name as an existing dataset.
• Submit an experiment/job
• Reference dataset during job run
• Update environment (e.g. changing dependencies updates the version)

Tree operations

• View dataset properties
• Dataset archive
• Log / output download (Navigate to a job, then navigate through folders to a log file. Right click -> Download)
• Jupyter extension integration ("Pick how to connect to Jupyter" list and recent connection in that list)
• Delete workspace

Files

• Test YAML language support (autocomplete, error validation)
• Test YAML template generation (Azure ML: Create Job command, verify that there are comments and pre-filled values in the YAML)

Remote e perience

• Test non-standard management endpoints (e.g. gov cloud)
• Test public access behind vnet

If hotfi es are required before release

• Make the hotfi change in master, then cherry-pick it to the release branch
• Test any affected areas from the Testing Checklist

3. Release to marketplace

• Create a release in Github. This Github release is just a way to package the code and track it in Github. Publishing a new release to VS Marketplace happens via the AzDO pipelines.
  • Create a new tag upon release with the new version number (e.g. v1.2.0)
  • Select the release branch (e.g. Rel1.2.0)
  • Select the previous release's tag for generating release notes.
  • Choose "Automatically generate release notes".
  • Submit the Github release.
    • This will trigger a pipeline run in the release pipeline: https://dev.azure.com/monacotools/Monaco/_build?definitionId=320&_a=summary There is a manual review step, so this pipeline will build the release candidate, but won't release until you approve.
• Approve the Publish step in the release pipeline to allow the pipeline to upload/publish the vsix to the marketplace.
• Download the latest version from the marketplace (note, it may take up to 30 minutes and restarting vscode multiple times to force it to refresh the marketplace). Do a quick test to ensure the extension works as expected.