Skip to content
This repository has been archived by the owner on Aug 9, 2019. It is now read-only.

enhance new release vs new version split #371

Open
asdkant opened this issue Apr 11, 2018 · 1 comment
Open

enhance new release vs new version split #371

asdkant opened this issue Apr 11, 2018 · 1 comment

Comments

@asdkant
Copy link

asdkant commented Apr 11, 2018

When one does a yaourt -Su, it lists the packages to update in the following fashion:

==> Package upgrade only (new release):
(list of packages with a new revision)

==> Software upgrade (new version) :
(list of packages with a new version)

Meaning, if a package start at version 3.7.1-2, if the new version is 3.7.1-3 (the -3 changed) it goes to the first list while if the new version is 3.7.2-1 (the .2-1 changed) it goes to the second list. This is not all that helpful, since a lot of packages update from A.B.C to A.B.(C+1) without changing much. It'd be more useful to let the user decide how to split the list of updates.

The simplest way would be to define a split behavior config: in a A.B.C-D scheme, one would be able to configure where is the limit between a version change and a small release.

A nicer approach (from the user's point of view) would be to be able to define a default behavior and lists of packages that fall in each possible behavior. For example, some programs follow the old linux versioning style (A is major version, B is release, C is small release), while others follow the firefox/chrome/new linux style (A is release).
The lists would need to be created, but that effort can be crowdsourced once the functionality is there :-D (or someone with historical info on package versions can do a decent first estimation with a script)

@f2404
Copy link
Collaborator

f2404 commented Apr 11, 2018

yaourt is just following the Arch package naming standards which are described here and here.
More specifically, the number after the - represents PKGBUILD version while the version string before the - represents the software version and matches the upstream versioning.
The separation is clear in the sense that if you see a package in the Software upgrade (new version) section, you know that it's been updated by the upstream. How much it has changed in fact, that you cannot tell without looking into that software's changelog or release notes.

To your proposal, it seems to me like a huge work but providing doubtful benefits.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants