Release number

[daiyam]

Hi @stripedpajamas,

I think we need to add a release number in addition of the package number. That way, when we find a bug in a release, we coud re-release the package with an augmented release number. (Like for arch https://wiki.archlinux.org/title/PKGBUILD#pkgrel)
1.58 was problematic because of this. If we had that, we could have pushed a fix sooner.
1.59 could have been a bigger issue due to the bug fixed by #787.

What do you think?

[daiyam]

@stripedpajamas I've been able to add release number on my build, here the patch: https://github.com/zokugun/MrCode/blob/master/patches/build-version.patch
The release number format is the year (2 digits) and the day of year (3 digits) (ex: 1.59.1+21241).
I used that format due to limitation in Inno Setup (windows) where part of the version have to be a number less than 65536.
We will see if the years 2060, if we need to change the format ;)

[daiyam]

@paulcarroty @GitMensch Could I get your feedback on this topic? Thx

[GitMensch]

I'd totally go for that, sounds like a good solution for Inno. We would have needed an option for a decoupled update before, too.
Not sure if that version number would work for Debian/CentOS/... @paulcarroty likely has insights.

[stripedpajamas]

Patch looks pretty small so this seems like a good idea to me. Like @GitMensch said, I don't know how it will affect Linux package managers.

[daiyam]

I don't know how it will affect Linux package managers.

I will try to ask them...

[paulcarroty]

I think we need to add a release number in addition of the package number. That way, when we find a bug in a release, we could re-release the package with an augmented release number.

It actually works for Linux packages: deb, rpm and appimage. I don't recommend to change this logic.

The release number format is the year (2 digits) and the day of year (3 digits) (ex: 1.59.1+21241).

Problem: waiting a day for hotfix.

[daiyam]

Actually, right now, any hotfix would have to wait to a new release of VSCode because the the update processes are looking at the tag name (1.61.2, https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/-/blob/master/updaterepos.sh) or at the VSCode's commit id (6cba118ac49a1b88332f312a8f67186f7f3c1643, https://github.com/VSCodium/versions/blob/master/linux/x64/latest.json).
No update processes are using those dates.

I'm trying the resolve this issue! The format isn't perfect but it's working for all platforms.

[paulcarroty]

No update processes are using those dates.

You're wrong. How it works in Linux:

• updaterepos.sh fetch all packages from latest tag, it can be old version or new version
• package manager compare the versions, if they are identical then compare their releases
• release is the build Unix time, so newer release always bigger than older
• if hotfix released I can trigger rebuild and it will be delivered in ~2 minutes

How new shiny format breaks stability:

• one release per day, it can be several builds with the same release - lack of clarity
• even if hotfix releases and I'll trigger rebuild a package manager will ignore the update - wait next day or week for a new build

[daiyam]

Looking into the control and spec files, I can tell I was wrong.
Here what I found:

• deb: Version: 1.61.0-1633724859
• rpm: Version: 1.61.0 \ Release: 1633724940.el7

Here what it would be with the new release number:

• deb: Version: 1.61.0+21280-1633724859
• rpm: Version: 1.61.0+21280 \ Release: 1633724940.el7

Do you understand with existing release numbers (1633724859), there is not normal way to have 2 packages (rpm or deb) with the same VSCode version (1.61.0)?
We could delete the existing packages and rerelease them. Yes, deb and rpm managers might pickup those new packages but not on Windows, macOS or maybe other linux package managers.

[paulcarroty]

Here what it would be with the new release number:

No way, deb & rpm versioning are different than Arch or whatever you know.

We could delete the existing packages and rerelease them.

🤓 🤣

I'm leaving the discussion 'cause my position is constantly ignored.

[daiyam]

I'm leaving the discussion 'cause my position is constantly ignored.

If it was the case I wouldn't be here discussing it with you ;)

[GitMensch]

As I see it: rpm & deb don't need the version adjustment "at all", because their versioning is depending on whatever was built + epoch.
@daiyam: You seem to think that 1.60.0 won't be updated while Paul said the newer Release part is enough for that.

@paulcarroty: An update on these environments are never done with the "check for update" variant, but only by the package manager [and those do take the Release part into account], correct? Similar for the appimage which is always a complete manual update.
So I guess you we likely have disabled the "check for update" feature of vscode there, correct?

So this actually only leaves:

• Triggering the auto-update on Win32, I guess we need a version update there, don't we?
• Check if/where we can include the epoch there.
• Do something similar on the Win32 build as it is on the Linux side: fetch the "latest" Release (not a tag), get version number from there, somewhere include the epoch.

[daiyam]

Currently, what's need to be done to generate a hotfix?

• delete the current release
• launch the workflows
• wait

What's happening then?

• deb & rpm package managers are updating their install
• macOS and Windows installs won't update because it's comparing the VSCode's commit id (the same between the 2 releases)
• package managers would complain because their database reference deleted files
• how the user know which version they are using or when they are posting a bug? Should we ask for the build date of the app?

My proposal is the best solution I can think of. It's working on all platforms.
Yes, it's limiting to one release per day. Is that a big issue?

Based on https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/, the version in rpm will need to be like 1.61.0.21280.

[daiyam]

Hi all, we need a solution to able to release a hotfix. (minor issue #989 for 1.64)

If my solution isn't good, could you provide a cross-platform one? Thx

[paulcarroty]

@daiyam you're free to implement any working solution tho, I will not help/criticize 'cause war in 🇺🇦 and my time is crazy limited. Good wind!

P.S. Do not remove old releases, they are useful if something goes wrong.