Version string

Today I discovered that Debian is going to distribute our Crunch:

https://tracker.debian.org/pkg/crunch-dxtc

That's nice!

But then comes the question of the version string.

That testing package use our tags like unvanquished/0.56.2 for releases, which is very good.

Indeed, every-time we release the Unvanquished game, we also release the Dæmon game engine, and we also release the Crunch tool. And on every release we write this tag.

So yes, all those unvanquished/x.x.x tags are actual releases of crunch: those tags are applied on stabilized branch, that stabilization being done as part of the Unvanquished and Dæmon stabilization.

But the 0.56.2 version for a crunch package looks wrong. As said in the readme, the version is 1.04U, because it is based on 1.04 version on crunch, with U for Unity variant. And since 0.56.2 is smaller than 1.04U, this looks a bit weird.

So I suggest that “1.05U” be the major version. Crunch interfaces are stable, this will probably never change. But then we can concatenate a string. For example we can version it 1.05.xU were x is a number we increment everytime we do a new unvanquished/x.x.x release. So we would have tags like v1.05.42U or v1.05.138U.

As a side note, I may start building binaries for Crunch at some point. I will not do that on every Unvanquished release (too much work!), but from time to time I would build some binaries that would match the latest release tag at the time, and then such version string would be used for the tarballs as well.

Distributions like Debian wouldn't need to match the irregular cycle of me building (or not) Crunch, they only have to follow our unvanquished/x.x.x tagging rhythm, exactly like the work-in-progress Debian crunch package already does.

Also since the release cycle is the one of Unvanquished and follows unvanquished/0.56.2 tags, the package could just use a version string like 1.05.0.56.2U or 1.05U0.56.2. It looks a bit cryptic though.

Well this release for every Unvanquished release scheme seems not so great for packagers since it would create unnecessary work by adding new versions even when there are no significant changes. Like even if only the README was changed there will be a new tag.

Also since the release cycle is the one of Unvanquished and follows unvanquished/0.56.2 tags, the package could just use a version string like 1.05.0.56.2U or 1.05U0.56.2. It looks a bit cryptic though.

It looks like the U is for Unvanquished 😛

Well this release for every Unvanquished release scheme seems not so great for packagers since it would create unnecessary work by adding new versions even when there are no significant changes. Like even if only the README was changed there will be a new tag.

On the other hand, it makes sense to repackage when the man page changes. And if a package ships the README to be provided in /usr/share/doc, then it also makes sense to upgrade the package. The things that will likely never affect a package are the CI stuff. But well, we can live with that.

Also since the release cycle is the one of Unvanquished and follows unvanquished/0.56.2 tags, the package could just use a version string like 1.05.0.56.2U or 1.05U0.56.2. It looks a bit cryptic though.

It looks like the U is for Unvanquished 😛

We can also be bold and go the 3.0 way.

Why 3? Because some people already been bold at naming their crunch “Crunch 2”:

https://github.com/FrozenStormInteractive/Crunch2

But that “Crunch 2” is based on a code older than Unity's crunch…

Binomial Crunch 1.04
 ↓            ↓
 ↓            FrozenStorm Crunch 2
 ↓
Unity Crunch 1.04 (U)
 ↓
Dæmon Crunch 1.04U

If we go the Crunch 3 way, we would just increment the next number: 3.0, 3.1, 3.54, 3.127, 3.1337…

I think the lower cost for us is to use 3 as major version (single digit, higher than both 1.04 and 2), then the Dæmon version.

So on Unvanquished/Dæmon 0.56.3, Crunch becomes Crunch 3.0.56.3. It's a bit long and noisy, but very easy to script.

Ourselves can add this tag as part of the Dæmon release: it's just another command to paste to create a tag, and if we don't create a tag, then peoples like that Debian maintainer can just parse the current unvanquished/0.56.2 tag, strip unvanquished/ (like he does) and prefix it with 3.

I just sent an e-mail to Sébastien Noel (the said Debian maintainer) to invite him to this conversation. 🙂️

I just sent an e-mail to Sébastien Noel (the said Debian maintainer) to invite him to this conversation. 🙂️

Hi! thank you for inviting me here 🙂️
I have no strong opinion on this, as long as versions goes up I'm happy ^^
Be it 3.0.56.3, 105u.0.56.3, 20260804, or whatever works for you

@twolife

Hi @twolife and welcome! 👋️

It looks like the 3.0.56.3 format is the best idea I had.

In previous comments I may have forgotten to mention that the big value of 3 makes it obvious there have been huge changes, so the U indication becomes less needed.

So not only that numbering is very likely the least costly solution, but fits all the needs to make it obvious there are lots of work being done here and that big changes happened. Dæmon Crunch is definitely not a minor update over others Crunch, and a big number helps to carry that message.

@twolife

So what I propose is that in the Crunch source we change the display version string to be just 3. The other numbers are just revisions, we don't need to hardcode them. In the Readme we also advertise Crunch as “Crunch 3”. And we state here that the decision is that the Crunch version is 3.x where x is the number in the most recent unvanquished/x tag. And once those changes are made public, then people like @twolife can start prepending 3. to the Unvanquished version number.

@slipher do you have any comment on that proposal?

Also we are lucky that Unvanquished has some 0.x long-term version, so using 3.<unv> for Crunch doesn't pressure us to bump to 4 anytime soon (it will probably never happen, even when Unvanquished reaches 1.0).

Sounds all right

I propose to do the version bump after those two fixes are merged:

With those two things merged, I will finally not be aware of any Crunch limitation anymore.

It would actually be really good if the Bold Version Bump also crowns that actual milestone.

This would also help other things, for example Urcheon does a lot of image preprocessing before feeding tools like Crunch, just to “sanitize” and “optimize” the input. If the need for before-hand sanitization and optimization is removed from Crunch before the version 3, then it would be easy for tools like Urcheon to look for the actual Crunch version to start with a number ≥ 3. Actually I may also add a --version option that would just print 3 as a start. 😁️

One problem with version number 3 is that looking for crunch 3 will bring that other crunch 3:

There also exist an ocaml-crunch 4.

So anyway we can't really avoid collisions.

Navigation Menu

Repository navigation

Version string #95

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Version string #95

Description

Activity

illwieckz commented on May 11, 2026

slipher commented on May 11, 2026

illwieckz commented on May 12, 2026

illwieckz commented on May 12, 2026

illwieckz commented on May 12, 2026

illwieckz commented on Aug 4, 2026

illwieckz commented on Aug 4, 2026

twolife commented on Aug 4, 2026

illwieckz commented on Aug 4, 2026

illwieckz commented on Aug 4, 2026

illwieckz commented on Aug 4, 2026

slipher commented on Aug 4, 2026

DolceTriade commented on Aug 4, 2026

illwieckz commented on Aug 5, 2026

illwieckz commented on Aug 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions