Vscode-powershell: Move to date-based versioning for the extension

Created on 15 Apr 2019  路  2Comments  路  Source: PowerShell/vscode-powershell

Maintaining a preview and stable channel of the PowerShell extension in the VSCode marketplace, we've hit a couple of painful issues:

  • npm uses semver v2 (like a lot of PowerShell software), the VSCode marketplace uses semver v1.
    Between x.y.z-label and x.y.z.w, we only have x.y.z. Trying to keep our versioning consistent with
    PowerShell modules (since PowerShellEditorServices is a module) while also making it work in the
    VSCode marketplace has meant we've had to use dual versioning for previews.
  • The VSCode Marketplace, unlike NuGet or the PowerShell Gallery, doesn't allow version unpublishing. There's no public supported way to end publication of a version. We can't fix that directly, but adopting a monotonically increasing versioning scheme could benefit us there.

After discussing the issue somewhat offline, there are other extensions in the VSCode Marketplace that use semver v2 or that have preview channels that manage the complexity of this partially using date-driven versions. For example, the Python extension.

My proposal is to use a YYYY.MM.DD version scheme.

However an alternative might be:

YYYY.MMDD.ReleaseVersion

But I want to discuss it here so we can try to pick up any pros and cons

Issue-Discussion

Most helpful comment

Because the PS extension is not software that is consumed by others like a library, using another versioning format seems to be not an issue, especially since the majority of user's are on the latest version anyway due to auto-update. To the users a datetime based versioning gives them more information about how recent it is, similar to the Windows OS.
Should they add the preview-feature to the marketplace at some point, then things might get complicated but for now, I'd be OK with it.

All 2 comments

Update

The Python extension actually uses: YYYY.MM.Revision. This seems like a good solution

Because the PS extension is not software that is consumed by others like a library, using another versioning format seems to be not an issue, especially since the majority of user's are on the latest version anyway due to auto-update. To the users a datetime based versioning gives them more information about how recent it is, similar to the Windows OS.
Should they add the preview-feature to the marketplace at some point, then things might get complicated but for now, I'd be OK with it.

Was this page helpful?
0 / 5 - 0 ratings