@@ -70,16 +70,24 @@ Microsoft. The comments are manual steps.
70
70
71
71
``` powershell
72
72
Import-Module ./tools/ReleaseTools.psm1
73
- New-Release -PsesVersion <version> -VsceVersion <version>
73
+ New-ReleaseBundle -PsesVersion <version> -VsceVersion <version>
74
74
# Amend changelog as necessary
75
75
# Push release branches to ADO
76
- # Permit both pipelines to draft GitHub releases
77
76
# Download and test assets
78
77
# Check telemetry for stability before releasing
79
78
# Publish draft releases and merge (don't squash!) branches
80
79
# Permit vscode-extension pipeline to publish to marketplace
81
80
```
82
81
82
+ If rolling from pre-release to stable, use:
83
+
84
+ ``` powershell
85
+ New-Release -RepositoryName vscode-powershell -Version <version>
86
+ ```
87
+
88
+ This is because we do not change the version of PowerShell Editor Services between a
89
+ pre-release and the subsequent stable release, so we only need to release the extension.
90
+
83
91
### Versioning
84
92
85
93
For both our repositories we use Git tags in the form ` vX.Y.Z ` to mark the releases in the
@@ -92,7 +100,7 @@ mark any specific release, that is the point of the tags.
92
100
For PowerShellEditor Services, we simply follow semantic versioning, e.g.
93
101
` vX.Y.Z ` . We do not release previews frequently because this dependency is not
94
102
generally used directly: it's a library consumed by other projects which
95
- themselves use preview releases for beta testing.
103
+ themselves use pre- releases for beta testing.
96
104
97
105
For the VS Code PowerShell Extension, our version follows ` vYYYY.M.X ` , that is:
98
106
current year, current month, and patch version (not day). This is not semantic
@@ -102,34 +110,40 @@ release on a chronological schedule: we release based on completed work. If the
102
110
month has changed over since the last release, the patch version resets to 0.
103
111
Each subsequent release that month increments the patch version.
104
112
105
- Before releasing a "stable" release we should almost always first release a
106
- "preview" of the same code. The exception to this is "hotfix" releases where we
107
- need to push _ only_ bug fixes out as soon as possible, and these should be built
108
- off the last release's codebase (found from the Git tag). The preview release is
109
- uploaded separately to the marketplace as the "PowerShell Preview" extension. It
110
- should not significantly diverge from the stable release ("PowerShell"
111
- extension), but is used for public beta testing. The preview version should
112
- match the upcoming stable version, but with ` -preview ` appended. When multiple
113
- previews are needed, the patch version is incremented, and the last preview's
114
- version is used for the stable release. (So the stable version may jump a few
115
- patch versions in between releases.)
116
-
117
- For example, the date is May 7, 2022. The last release was in April, and its
118
- version was ` v2022.4.3 ` . Some significant work has been completed and we want to
119
- release the extension. First we create a preview release with version
120
- ` v2022.5.0-preview ` (the patch reset to 0 because the month changed, and
121
- ` -preview ` was appended). After publishing, some issues were identified and we
122
- decided we needed a second preview release. Its version is ` v2022.5.1-preview ` .
123
- User feedback indicates that preview is working well, so to create a stable
124
- release we use the same code (but with an updated changelog etc.) and use
125
- version ` v2022.5.1 ` , the _ first_ stable release for May (as ` v2022.5.0 ` was
126
- skipped due to those identified issues in the preview). All of these releases
127
- may consume the same or different version of PowerShell Editor Services, say
128
- ` v3.2.4 ` . It may update between preview versions or stable versions (but should
129
- not change between a preview and its associated stable release, as they should
130
- use the same code which includes dependencies).
131
-
132
- ### Pending Improvements
133
-
134
- * ` Update-Changelog ` should verify the version is in the correct format
135
- * ` Update-Changelog ` could be faster by not downloading _ every_ PR
113
+ Before releasing a stable version we should almost always first release a preview of the
114
+ same code, which is a _ pre-release_ . The exception to this is hotfix releases where we
115
+ need to push _ only_ bug fixes out as soon as possible, and these should be built off the
116
+ last release's codebase (found from the Git tag). The pre-release is uploaded to the
117
+ marketplace using the ` --pre-release ` flag given to ` vsce ` (the CLI tool used to do so).
118
+ The previous separate "PowerShell Preview" extension has been deprecated in favor of using
119
+ the marketplace's support for [ pre-releases] [ ] on the stable and now one-and-only
120
+ extension.
121
+
122
+ Because the marketplace does not actually understand Semantic Versioning pre-release tags
123
+ (the ` -preview ` suffix), the patch numbers need to increment continuously, but we append
124
+ ` -preview ` to _ our_ version in the changelog and Git tags. When multiple pre-releases are
125
+ needed, the patch version is incremented (again because the marketplace ignores the
126
+ pre-release tag, we can't do ` -alpha ` , ` -beta ` etc.). Since migrating to a single
127
+ extension, the stable release has to increment one more after the last pre-release. So the
128
+ stable version may jump a few patch versions in between releases. Furthermore, the
129
+ ` preview ` field in the extension's manifest (the ` package.json ` file) is _ always_ ` false ` ,
130
+ even for pre-releases, because the marketplace takes the information from the latest
131
+ release inclusive of pre-releases, hence it was causing the one-and-only extension to look
132
+ like it was in preview. This is also why the icon no longer changes to the PowerShell
133
+ Preview icon for pre-releases. When they support pre-releases better (ideally that means
134
+ supporting the pre-release tags in full) we can revisit this.
135
+
136
+ [ pre-releases ] : https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions
137
+
138
+ For example, the date is May 7, 2022. The last release was in April, and its version was
139
+ ` v2022.4.3 ` . Some significant work has been completed and we want to release the
140
+ extension. First we create a pre-release with version ` v2022.5.0-preview ` (the patch reset
141
+ to 0 because the month changed, and ` -preview ` was appended). After publishing, some
142
+ issues were identified and we decided we needed a second pre-release. Its version is
143
+ ` v2022.5.1-preview ` . User feedback indicates that pre-release is working well, so to
144
+ create a stable release we use the same code (but with an updated changelog etc.) and use
145
+ version ` v2022.5.2 ` , the _ first_ stable release for May (as ` v2022.5.0 ` was skipped due to
146
+ those identified issues in the pre-release). All of these releases may consume the same or
147
+ different version of PowerShell Editor Services, say ` v3.2.4 ` . It may update between
148
+ pre-release versions or stable versions, but must not change between a pre-release and the
149
+ subsequent stable release, as they should use the same code which includes dependencies.
0 commit comments