Posted under snapcraft, but I assume this affects snapd as well.
My snaps fail validation if the version string is > 32 characters. This limit seems arbitrary and is too short. For example, I’ve been working on https://github.com/mcphail/ast/tree/snap_support where I use version: git. Upstream uses quite long git tags. If I then iterate on a dirty tree I get version strings like 2020.0.0-beta1+git69.ba292c88-dirty which exceed the arbitrary length and halt snapcraft in its tracks. It would be better if the 32 character limit was increased to a much higher limit.
The version string is supposed to convey information to the user. What are you trying to communicate with such a long version string?
The version string is printed in full in snap list. At 32 characters, that means it can use up over a third of the columns available in the default 80-column terminal. That already seems like a lot. I’d be against increasing it.
I have also had an application which has a long version string get rejected by the store. It previously built but suddenly broke when it went over 32 so I had to step in and modify the version string.
Issues while validating properties: The 'version' property does not match the required schema: '0.82.22-beta-20190914-1332-22-g21faa9230' is too long (maximum length is 32)
I’m not convinced optimising everything for snap list is always the best way. snap list already overflows to a second row in a default 80 column terminal on my computer.
In this case, it is indicating the precise version from the upstream git repo. That seems valuable enough to be communicated to the user, in my opinion.
I have just had this again. This time I’m trying to contribute to a fix to an upstream project. Their build system is written in go (as is the project) and comprises (project_version)(tag)(dirty)(branch_name) so while I’m developing I get this
1.3.1-rc.1+2-g6b570ee-dirty-add-missing-utilities which overflows the 32 char limit. It’s 50.
I can either edit the upstream project changing their build system to reduce that, or I could make by branch name something meaningless and short like “fix-5288” to indicate the issue I’m fixing, at least.
1.3.1-rc.1+2-g6b570ee-dirty-fix-5288 which still overflows the 32 char limit. This is 37 chars.
WAT!
1.3.1-rc.1+2-g6b570ee-dirty-wat - this is 32 characters.
I think, rather than stipulate a size to account for all places it is displayed, we should be allowing the field to be free-form and marshall the output to fit the places when it is displayed not when it is created. i.e. if the region to display the data is short and the data would overrun then truncate and append ... or some other indicator that it is truncated.
The limit is implemented in other places, so it needs coordination to remove it, a snapd PR is not enough. In any case it’s unlikely that we will simply remove it. We might increase it.
while I understand where that is coming from, and I understand how it could make sense for something on edge or in a branch (but branches have names as well). It’s not completely clear we want to facilitate that kind of version for anything in more stable channels. That’s our tension here apart terminal size limits.
The version field is meant for informational purposes, it has zero other uses. Therefore we want to facilitate the developers to use whatever version they desire. Imposing limits on a free-form field that is only useful for informational purposes is unfair on the developer who expects to be able to put any informational text they desire in there.
In what situations to you envisage that a developer wants a detailed version in edge but never under any circumstances might want the same detailed version in other channels? I find it odd that you see uses in edge but not in the other channels. Surely the same usefulness is just as applicable in the other channels…
if that was the design there would no limit, but there is one. I also notice that these whole paragraphs don’t mention users anywhere which is a bit the crux here. The field is called version, not “tags” or label, at the end of the day there is some expectation that versions map a curated choice space where newer/higher is better.
Yet we don’t enforce that, so developers aren’t expecting it. We could enforce semver. We could enforce build numbers in the version field. We don’t. Why not? From what I can gather we don’t because we wanted it to be freeform.
The way I see the version field is an identifier that allows a support representative to ask a user “What version is that?” where the user tells them the value in the version field and the support representative uses that information to help the user. Yes, users like to see that they are on a higher number than two weeks ago, but that doesn’t actually benefit them in any way other than warm fuzzies and they can get that feeling from the revision number anyway.
Yes, users already get a revision number. I don’t like the aesthetics of long version strings either, but I’m not the upstream. We shouldn’t be setting limits based on what a ZX Spectrum could fit on one line of text.
From my perspective there should be an upper limit (lest we tempt fate for buffer overflows in future software) but that upper limit should be ridiculously large and well documented. I’d suggest 4096 bytes plus null terminator, but wouldn’t expect anyone to actually use it.
Both version and revision are intended for users (and developers). Of the two version is and is meant to be the friendlier one.
In general revisions can only be compared for equality and are used to check for updates. They can help know if different machines have the same bits but a higher revision just means uploaded to the store more recently without any further implications.
I discussed the situation with the people that originally decided the limit and other affected components (store/snapcraft). While versions are free form still users are their audience too and the limit is intended as a nudge to friendly versions.
We understand that there is a flow from CI/build/testing to users, and in channel terms from edge to stable where the metadata audience evolves from mainly developers to include general users. But for simplicity any rule for version here that applies for stable needs to apply all the way back to edge.
There is a feature coming which is revision attributes that will allow to attach to revisions less constrained and more build/developer oriented metadata. This should be able to store more comfortably what upstreams use as versions without further considerations.
