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)
When one does a
yaourt -Su, it lists the packages to update in the following fashion:Meaning, if a package start at version
3.7.1-2, if the new version is3.7.1-3(the -3 changed) it goes to the first list while if the new version is3.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-Dscheme, 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)