Differentiate vsix package version

[llFreetimell]

What?

Let's differentiate version of vsix packages, which are generated by

• local environment
• Daily Publish by github action
• Release artifact

Why?

Currently, all the versions are same even they are created by different code base.
It makes users confused.

Suggestion

• local environment
  • one-vscode-local.vsix
  • one-vscode-local-abcd1234.vsix (commit hash id)
  • one-vscode-local-20130102.vsix (date)
  • one-vscode-local-abcd1234-201301021234.vsix (commit hash id + date)
• Daily Publish by github action
  • one-vscode-0.4.0-abcd1234.vsix (commit hash id)
  • one-vscode-0.4.0-20230102.vsix (date)
• Release artifact
  • one-vscode-0.4.0.vsix

Considerations

• Changing output file name is easy, but changing real version in the package metadata is maybe complex in local environment
  • To package even with unstaged/staged changes, vsce package should be used. It cannot change version
  • To use vsce package <version>, git should be clean(No unstaged/staged changes)
• When major version of release is changed, it will be different with the major version of nightly build

[jyoungyun]

• Changing output file name is not that difficult, but changing real version in the package metadata is maybe complex.

We can change output package name without modifying the package.json code.
vsce package <version>
This code lets you create the package you want.

[jyoungyun]

I saw your draft code. The code generates a different package file according to the build mode.
Um, today I introduced #1479 PR for reusing workflow.
I think, if the build type is added in the publish extension and the build type is the same as nightly, it is possible to call npm run createpkg-nightly instead of generating package version by vsce package command.
I don't prefer to add build type to publish extension because there are times when this code create more and more branches..... However, it is also a simple way. Do you have any better ideas about this?

[llFreetimell]

I think my description was not enough, so I updated main comments :)
And this is about the versioning, so I don't care about detailed implementation at here :D

---

We can change output package name without modifying the package.json code.
vsce package

To package all the things, even with unstaged/staged changes, we cannot use vsce package <version> because it requires "clean git directory". (It means that there should be no uncommitted changes)
In local environment, there are usually uncommitted changes. Furthermore, package.json is updated even the user do not want.
That's why changing real version would be complex for local environment :(

I don't prefer to add build type to publish extension because there are times when this code create more and more branches..... However, it is also a simple way. Do you have any better ideas about this?

For now, I think just changing one line in the publish extension script :D

// Before
vsce package

// After
VER=$(npm version --no-git-tag-version --no-commit-hooks minor | cut -c2-)
vsce package --no-git-tag-version ${VER}-$(git rev-parse --short HEAD)"

Instead of git commit id, date can be used. Just for example :)

[jyoungyun]

For now, I think just changing one line in the publish extension script :D

We use publish extension workflow both nightly and official release. So if we change the vsce package command at once, it will be applied to official release workflow too.

We have two choice for solving this problem.

1. Use pre-release as nightly release, and fixed the pre-release packaging code only.
   

   ONE-vscode/.github/workflows/publish-extension.yml

   Lines 31 to 34 in 36f886e

   	- name: Create vsix package (pre-release)
   	if: ${{ inputs.prerelease == 'true' }}
   	run: |
   	vsce package --pre-release

2. Introduce build_type inputs parameter in Publish extension workflow.
   draft pr: [draft] Use a separate version in nightly build mode #1481

Please give me your opinion. :)

[llFreetimell]

For me, option 1 has following pros.

• Introducing build_type may cause worse maintainability.
• As nightly release is sort of pre-release, meaning is also natural

But I am not sure about following cons, because maybe I am misunderstanding something.

• GIthub Release Pages maybe changed so often because pre-release also has release note
• Nightly packages are uploaded to Marketplace so often, and users maybe embarrassed due to so many versions

If above cons are resolved, of they are all my misunderstanding, option 1 seems good :)
But basically, I am okay with both of them :D

[jyoungyun]

But I am not sure about following cons, because maybe I am misunderstanding something.

• GIthub Release Pages maybe changed so often because pre-release also has release note
• Nightly packages are uploaded to Marketplace so often, and users maybe embarrassed due to so many versions

Nightly release is released from nightly-release.yml file. And this workflow does not create release page and publish the extension package. It just uploads an artifacts to the GitHub Actions Summary page.

We can only enable the prerelease option in nightly release workflow.

But one thing we need to think about, if we set prerelease in official release, it also generates a package file with a special version of the rules that we set. However, it is a prerelease file, so it is okay, I think.

[llFreetimell]

And this workflow does not create release page and publish the extension package. It just uploads an artifacts to the GitHub Actions Summary page.

If so, both of cons are resolved :)

But one thing we need to think about, if we set prerelease in official release, it also generates a package file with a special version of the rules that we set. However, it is a prerelease file, so it is okay, I think.

I agree with you. As pre-release is not official release, using special version(e.g. 0.5.0-abcd1234) seems okay in perspective of "Official version can only be used for official release" :D

[jyoungyun]

@lemmaa

We concluded to release from nightly release to pre-release with special version (e.g. 0.5.0-abcd1234).
It does not modify the package.json file. It is applied to nightly release CI through the publish-extension workflow.

We have considered to give a new run command for packaging extension with special version. However, it requires the clean git directory so we decided not to provide it to individual user. related comment

What about our suggestion? Please let me know, if you have a good idea or if we missed anything. :)

[lemmaa]

We concluded to release from nightly release to pre-release with special version (e.g. 0.5.0-abcd1234). It does not modify the package.json file. It is applied to nightly release CI through the publish-extension workflow.

I fully agree with you.

We have considered to give a new run command for packaging extension with special version. However, it requires the clean git directory so we decided not to provide it to individual user. related comment

Reasonable. If so where do we store the new run command?

What about our suggestion? Please let me know, if you have a good idea or if we missed anything. :)

The name or build version of the package being built locally is not yet clear for me. Is it one-vscode-local.vsix?

[jyoungyun]

Reasonable. If so where do we store the new run command?

We can add new package command for local user like this. It is not working if the directory is not clean. However do we need this?

The name or build version of the package being built locally is not yet clear for me. Is it one-vscode-local.vsix?

We can not change the vscode pacakge name. However we can change the version number with specific postfix (e.g. one-vscode-0.5.0-abcd1234.vsix) if we introduce new package command.

[llFreetimell]

We can not change the vscode pacakge name. However we can change the version number with specific postfix (e.g. one-vscode-0.5.0-abcd1234.vsix) if we introduce new package command.

This is reversed maybe.
We can change filename (e.g. one-vscode-0.5.0-abcd1234.vsix) easily.
But we cannot change version without clean directory and updating package.json.

[lemmaa]

#1474 (comment)

Reasonable. If so where do we store the new run command?

We can add new package command for local user like this. It is not working if the directory is not clean. However do we need this?

@jyoungyun , I misunderstood. In conclusion, I understand that the package command is not added.

[llFreetimell]

Adding package command for itself is not difficult :)
But, as each methods have clear pros and cons, I am not sure which one would be better if we add package command :(

• vsce package -o one-vscode-local-commitID_202301012359.vsix
  • Output File : one-vscode-local-commitID_202301012359.vsix
  • Version : 0.4.0
  • Pros
    • Package can be created fully with current status (Any unstaged changes are package together)
    • package.json is not changed
  • Cons
    • When user install the output file, version is not distinguishable
• vsce package local-commitID
  • Output File : one-vscode-local-commitID.vsix
  • Version : local-commitID
  • Pros
    • When user install the output file, version is distinguishable
  • Cons
    • Directory should be clean, which means any unstaged changes are not allowed
    • package.json is updated regardless of user's wish

[jyoungyun]

This is reversed maybe.
We can change filename (e.g. one-vscode-0.5.0-abcd1234.vsix) easily.

Oh we can change the file name by using -o option. We can use this command in local build or nightly build. :)