It is typical that consecutive releases for a specific mainline of the product will be following chronologically, but it's not a good absolute assumption.
It was observed that sometimes an earlier commit (in the version tree) might actually be tagged and released after a later one which is still a valid situation.
Example:
$ grep "^\*" makelib-1.10.0/makelib.spec
* Mon May 14 2018 Waldek Maleska <waldek.maleska@nokia.com> - 1.10.0-146437
[...]
* Wed Nov 22 2017 Red Acted <red.acted@nokia.com> - 1.5.0-20
* Mon Nov 27 2017 Red Acted <red.acted@nokia.com> - 1.4.0-19
* Thu Nov 23 2017 IRed Acted <red.acted@nokia.com> - 1.4.0-18
[...]
$ rpmbuild -ba makelib.spec [....]
...
Building target platforms: noarch
Building for target noarch
error: %changelog not in descending chronological order
Makefile:82: recipe for target 'dist/makelib-1.10.0-redacted.noarch.rpm' failed
Possible implementation ideas for sorting the releases:
by date unconditionally
by date based on flag (on by default), e.g. --sort-by-date
allow sorting by a predefined set of fields, e.g. date, tag: --sort-by={date|tag}
Personally I lean towards option (3), but it's up to debate. Input welcome.
It is typical that consecutive releases for a specific mainline of the product will be following chronologically, but it's not a good absolute assumption.
It was observed that sometimes an earlier commit (in the version tree) might actually be tagged and released after a later one which is still a valid situation.
Example:
Possible implementation ideas for sorting the releases:
--sort-by-date--sort-by={date|tag}Personally I lean towards option (3), but it's up to debate. Input welcome.