I know that autorelease has introduced some problems but it would be
good to keep a way to automatically bump releases. Every second we
could save from devs/maintainers is more time to do really useful
things.

Can't we have a central way to publish the "official list of package
releases''? It could be a file inside the git, but automatically
updated by a bot when we build packages for publishing. Any local
changes (git can track them without a history) or local commit will
introduce some "dirty tag" to the release number, similar to what
already happens with the openwrt build number (r9999+x-abcdef). For
example:

foo-1.3-34 (oficial built)
foo-1.3-34.2.abcd12ef+ ("2" local commits being the last one
"abcd12ef" and some extra ("+") uncommited changes)
foo-1.3-34+ (package with some extra ("+") uncommited changes)

If we have reproducible builds, we could bump that release only when
the final binary differs from the last one, skipping cosmetic changes
that do not change the final package but including external ones that
affect one or more packages. It would even avoid bumping subpackages
when the source changes when only some of them really changed.

If that would add too much noise to the history, that same official
list of packages could be published somewhere else. For example, it
could have a file with a list of commits on each branch and the
corresponding "official list of package releases". Something like:

master:
b97e5ac785960c13199239dd4821dd53f3801da3 master-00000454
6f729163b18fb5860f1aa5a5a0c8861a8e3f53ad master-00000454 <<< built bot
published this one
9179f484bfcb37e1c59e736b2a64c9583eb00356 master-00000453
...

master-454:
foo-1.3 34
bar-1.2 45
...

The client would download that list and iteratively look for the last
commit that is found in the list and download the official list of
packages. Count the commits since that commit used for publishing
(including those in the master file or local history) and adjust the
releases. If someone checks out a tagged commit or one used to publish
packages, all releases will match the official one. If not, it will
use some extra release numbers.

There might be a lot of improvements, like sorting the commit list,
plenty of different solutions that solve this problem and maybe some
of them already exist in other build solutions (like OBS). I just
don't like the idea of returning to manual management.

Regards,

Luiz

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to