determine versioning scheme #7

raboof commented 2022年10月31日 12:37:28 +01:00

should we base our version numbers on the most recent upstream Sway release that has been merged in?

should we base our version numbers on the most recent upstream Sway release that has been merged in?

raboof commented 2023年06月07日 11:39:46 +02:00

Especially now that in #8 we've decided to keep relatively close to Sway releases, keeping the Sway release number in our version number somehow sounds sensible.

Perhaps we should just tack an increasing number to the end, so the progression is something like 1.8.0.1, 1.8.0.2, 1.8.1.3, etc? Downside of that is that this definitely isn't semver, and we don't have a way to indicate major/minor releases of the Volare parts. That might be fine?

Especially now that in #8 we've decided to keep relatively close to Sway releases, keeping the Sway release number in our version number somehow sounds sensible. Perhaps we should just tack an increasing number to the end, so the progression is something like `1.8.0.1`, `1.8.0.2`, `1.8.1.3`, etc? Downside of that is that this definitely isn't semver, and we don't have a way to indicate major/minor releases of the Volare parts. That might be fine?

edmonds commented 2023年06月07日 20:26:11 +02:00

Other possibilities would be to reset the Volare component after each Sway version (1.8.0.0, 1.8.0.1, 1.8.1.0, 1.9.0.0) or to have a separate, delimited Volare version component (1.8+0.1.0, 1.8+0.2.0, 1.8.1+0.2.0, 1.9+0.2.1, etc.).

It's probably unlikely looking at Sway's version history, but appending a number could clash if Sway starts to use a 4th version component, e.g. they could release 1.9.1, 1.9.2, then go back and release 1.9.1.1. So I think I favor the delimited approach.

Other possibilities would be to reset the Volare component after each Sway version (`1.8.0.0`, `1.8.0.1`, `1.8.1.0`, `1.9.0.0`) or to have a separate, delimited Volare version component (`1.8+0.1.0`, `1.8+0.2.0`, `1.8.1+0.2.0`, `1.9+0.2.1`, etc.). It's probably unlikely looking at Sway's version history, but appending a number could clash if Sway starts to use a 4th version component, e.g. they could release 1.9.1, 1.9.2, then go back and release 1.9.1.1. So I think I favor the delimited approach.

raboof commented 2023年06月18日 21:28:30 +02:00

Other possibilities would be to reset the Volare component after each Sway version (1.8.0.0, 1.8.0.1, 1.8.1.0, 1.9.0.0)

Yeah that would work as well and maybe looks less 'weird' from the outside.

or to have a separate, delimited Volare version component (1.8+0.1.0, 1.8+0.2.0, 1.8.1+0.2.0, 1.9+0.2.1, etc.).

Delimiting is nice, on the other hand that might get confusing when distribution packagers also add their own extra delimited versioning.

It's probably unlikely looking at Sway's version history, but appending a number could clash if Sway starts to use a 4th version component, e.g. they could release 1.9.1, 1.9.2, then go back and release 1.9.1.1.

That indeed seems unlikely - even 3-number versions seem relatively rare for Sway.

> Other possibilities would be to reset the Volare component after each Sway version (`1.8.0.0`, `1.8.0.1`, `1.8.1.0`, `1.9.0.0`) Yeah that would work as well and maybe looks less 'weird' from the outside. > or to have a separate, delimited Volare version component (`1.8+0.1.0`, `1.8+0.2.0`, `1.8.1+0.2.0`, `1.9+0.2.1`, etc.). Delimiting is nice, on the other hand that might get confusing when distribution packagers also add their own extra delimited versioning. > It's probably unlikely looking at Sway's version history, but appending a number could clash if Sway starts to use a 4th version component, e.g. they could release 1.9.1, 1.9.2, then go back and release 1.9.1.1. That indeed seems unlikely - even 3-number versions seem relatively rare for Sway.