-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[discussion] unified scheme for snapshot versions #345
Comments
Nice write up, seems like a proper solution. I have one comment regarding "guessing" of a next version. Often, |
Well, having next version explicitely defined in the upstream code/documentation justifies using 'pre' somewhat, but there still is no guarantee that another version will not be released instead, messing everything up. "Post" way is bulletproof though. |
I've just ran into https://pypi.python.org/pypi/flake8-builtins/1.0.post0 Which makes me think that the only option is really verbose unique suffix such as |
I think you should take any standard version scheme and normalise all software to it. |
It is not possible. |
What about using
Do we really need We in nixpkgs often use just What if you want to package a second change at one day? Maybe @AMDmi3 do you plan to create a page with suggestions for package maintainers like this? I think this is a great initiative to align versioning in software repositorys! Have you invited the packaging community of the major repositorys? Some more opinions and ideas might be helpful and they might be more willing to adopt this when they had a chance to participate in the discussion. |
I disagree with "-" ideas. For long file names it might break to a second line in some WM and it will become unreadable. Also, these two extra chars do no bring any value. |
Well yeah, but i feel like you didn't read my reasons. We are talking about version numbers, not about date standards |
I doesn't have to be readable (though I don't see any readability problems with YYYYMMDD), it must be simple, unambiguous and close to schemes which are already widely used.
Also, some repositories do not support dashes in versions.
Yes, because when the actual version is released, it would automatically be ordered after Actually, I've just found out that from libversion perspective
These cases should not be separated, as the proposed snapshot scheme must coexist with past and future versions. Any scheme without prefix will break as soon as first official version is released. So the proposal is to treat all snapshots based on some upstream version, 0 if there isn't one. Actually even that will break if upstream releases e.g.
That's a very good question. Naive answer would be Actually, most repositories have local package revisions which could be used for this purpose. I guess the scheme should suggest using revisions, while libversion could handle snapshots specially and ignore everything past the date. This is OK, since the special handling would only be required in libversion, all local algorithms will still be OK with handling suffixes normally.
Not yet. I'm sure this topic will come up when repology is used by more people. |
Returning to this, alternative solution would be for individual repositories to convey information on that they are packaging a snapshot. As soon as we have this flag and a snapshot date, we could compare snapshots specially by comparing dates instead of versions. It could be further improved:
After repology/repology-rules#20 is done (not even started yet), we'll have all snapshots which use date version marked up, so we can extract this information from them. However if any repository wishes to convey this information directly, it's most welcome and could be used right away. Repology would need, roughly,
There are multiple ways to convey this data. The simpliest one would be to just use date suffix to the version ( |
Gentoo has a very clear policy:
BUT ;-) there is an exception when the upstream did not release any version and So as a generic rule, you can search for the suffix |
Gentoo's policy is no better than other repositories using random suffixes - it mixes up with upstream versions using |
And also |
FYI, in ALT we promote the following versioning scheme of git snapshots which is based on the idea implemented in https://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/git-version-gen (which in turn is used in many projects): |
Apologies per necro-bumping! I will mark myself here, because we at Nixpkgs are struggling at a similar problem. The format I am using is something like (late edits to reflect the current state - thanks @davidak for the reminder) |
@ldv-alt there's a rule back from 2018 which marks that specific scheme as incorrect. Thankfully that scheme hasn't gained wide adoption, as it's horrible in all aspects: not separating upstream and snapshot parts, needlessly long and uses commit hashes. Also violates RPM version policy. Actually, the whole sisyphus is currently pessimized for providing intolerable amount of fake versions (apart from snapshots, for which there's also nothing close to a single format). @AndersonTorres that's good, but as far as I can see, |
I think there is still no decision which format should be used in NixOS. It would be great if this issue results in a recommendation. |
The recommendation is in the issue body. |
@AMDmi3 Please elaborate. |
09.09.2021 01:41, Dmitry V. Levin пишет:
Also violates RPM version policy.
@AMDmi3 <https://github.com/AMDmi3> Please elaborate.
+1
|
It is mentioned in ALT own docs: It was mentioned in Fedora packaging guidelines, but it turns out it's now thankfully deprecated. |
I'm sorry to correct you, but the wiki page you're referencing is not a policy, let alone an RPM policy.
I'm sorry to correct you, but the Fedora document you're referencing is not an RPM policy. Anyway, RPM permits the kind of versioning I recommend for use in case of git snapshots, and ALT packaging policies have nothing against it. Like it or not, but the versioning scheme I recommend for git snapshots has its benefits and its users. |
Well, all I'm going to say is that this scheme will never be honored by Repology because it cannot be meaningfully compared neither to upstream, nor to other repositories, nor to other sources such as vulnerability databases. |
I am formulating a RFC to the NixOS community/organization. Until then, the mess will be there. |
Since versions produced by this versioning scheme are as easy to recognize as versions produced by other versioning schemes, I do not agree that they cannot be meaningfully compared with upstream versions, and you do not compare different snapshots between each other anyway. BTW, how can you explain the following: https://repology.org/project/hasher-priv/versions ? |
Adding YYYY-MM-DD to the version requires manual work. Here is an example of how git snapshot can be packaged:
Release tag consists of 3 parts. When upgrading to a new git snapshot, the first number is increased, when rebuilding an existing snapshot, the last number is increased. As a package maintainer, I just go to github or another place, study commits history, then copy the commit hash, change it in the spec file, then run I think other maintainers have a similar way of thinking and that is why I would not expect a wide adoption of naming schemes which require additional useless work like tracking date. |
No, they are not. Unlike any other snapshot schemes I've seen, they are completely indistinguishable. There is not a single property which can be reliably used to tell them from official versions.
Yes.
I've never required to add YYYY-MM-DD to the version.
There is no problem with this specific case at all, as For instance, Repology can (and does) safely treat it as the unmodified version, which won't generate nonexisting release, will be marked newest/outdated correctly and can be compared to NVD with release granularity. The lack of date prevents it from being compared with higher granularity, but we don't to that anyway and I don't think we should and will. However, it is still pessimized in a way that this version will not be treated as a new if it only comes from an RPM distro. Because the above mentioned "not policies" are widely used, there's no telling that the snapshot is based upon a real release, or a fake "next" release as the not policies suggest. There's no way to tell that by Release starting with |
Ah, thanks, I think I understood, so if ALT's version-release was VERSION.0.NUMBER.gitHASH instead of VERSION.0.NUMBER.HASH, it would be recognizable as a git snapshot. |
While the other problems with it remain, yes, at least it would be possible to reliably tell that it's not an upstream version. It won't allow to tell it from snapshots which can be compared to upstream though. |
On Fri, Sep 10, 2021 at 04:24:13AM -0700, Dmitry Marakasov wrote:
> Since versions produced by this versioning scheme are as easy to recognize as versions produced by other versioning schemes
No, they are not. Unlike any other snapshot schemes I've seen, they are completely indistinguishable. There is not a single property which can be reliably used to tell them from official versions.
These versions are upstream versions followed by .0.distance.digest suffix
where distance is a decimal number and digest consists of at least 4
hexadecimal digits, so they are clearly recognizable.
For example:
$ rpmquery elfutils
elfutils-0.185.0.54.b561-alt1.x86_64
$ rpmquery --qf '%{version}\n' elfutils \
| sed -E 's/^(.+)\.0\.([[:digit:]]+)\.([[:xdigit:]]{4,})$/\1\t\2\t\3/'
0.185 54 b561
> BTW, how can you explain the following: https://repology.org/project/hasher-priv/versions ?
> Is it the result of "the whole sisyphus is currently pessimized"?
Yes.
Unfortunately, such a blanket ban approach makes the whole repology.org untrustworthy.
|
No they are not. As can be seen by the link already given above, the probability is quite high for these hexadecimal digits to only consist of decimal digits, making a snapshot indistinguishable from a legal dot-separated numeric version:
Versions like these are used in the wild, in case you wonder. In some other cases, even if a hash contains
The very first thing Repology must do to be trustworthy is to prevent garbage from a misbehaving repository to be reported as a new upstream version to all other maintainers, and that we do. As I've already mentioned though, the discussed scheme is not the only and not the main cause for the ban - the amount of random made up versions from Sisyphus is, as the repository is the worst by the number of ignore rules I've had to add and maintain
by the number of known incorrect versions
and by the number of complaints, e.g. cases which actually affect users:
So please don't mention untrustworthiness. |
TL;DR: see Summary below
So, we have support for normal versions, and we now also have a special support for prerelease versions. However, we still have to ignore a lot of packages most of which are snapshots. Sometimes snapshots are necessary evil and cannot be avoided. For example, if the release has fatal bug, or when upstream is dead, but there are useful commits in the master branch.
Now I wonder if repology can improve the situation by suggesting some kind of unified unambiguous snapshot format, so snapshot versions from different repos COULD be comparable.
The ideas on format:
0.4.7
, the snapshot must be0.4.7something
, not0.4.8something
, because there should be no guessing on what the next version would be.YYYYMMDD
is an obvious choice.Well, I don't see many choices on a format here, it's obviously
1.2.3somethingYYYYMMDD
(orsomethingYYYYMMDD
when there's no past version). From repology point of view, it's the same as1.2.3.somethingYYYYMMDD
, so distros may use additional dot on their discretion.So, we have to decide what to use as
something
.git
,svn
,bzr
) as they are ambiguous and often used with "pre" meaning.patch
andpost
(I've just discovered the latter, and added support to libversion), but they are sometimes used upstream (hdf5, some python ports)So, either we have to invent a new keyword, which has apparent "post" meaning and is not used upstream, or we could use one of
post
orpatch
ignoring their use upstream (which is not that wide). Inventing a keyword seem to be preferable. So, the ideas?postsnap
post*
(e.g. allowpostgit
,postsvn
and whatever which begins withpost
, and compare them equally)plus
Additional thoughts:
pre
andpost
suffixes togit
/svn
/hg
/cvs
would be beneficial on a global scale.1.2preXXX
and1.2postXXX
would both be lesser to1.2
.Summary
When packaging snapshots, let's
post
keyword after it (anything allowed afterpost
, e.g.postgit
,postsvn
)The version of snapshot which comes after official
4.7
version may thus look like4.7postgit20170928
or4.7.postgit20170928
or4.7post20170928
See how it's better than:
4.7git20170928
(it is not known whether snapshot is taken before or after4.7
)4.7git1234f6a
(commit hashes are meaningless in versions, as they are not monotonic; however you may still append it:4.7postgit20170928.1234f6a
and I think we can still make it comparable in a sane way)4.8git20170928
,4.8pre20160928
(you are guessing which the next version would be, and you may be mistaken. For instance, it may be4.7.1
which would make the version go backwards)Note that this schema is not something synthetic and new, it's just a refinement of widely used
VERSIONwordDATE
schema which provides an explicit and unambiguous information on a snapshot which was packaged. As a side affect, it makes it possible for repology to compare these snapshots.The text was updated successfully, but these errors were encountered: