[RFC] Policy for PKG_RELEASE bumps

[Sander Vanheule]

Hi Paul,

Following our brief discussion on IRC, here are my remarks again, so
others can also comment on them. I'm still pretty new to this packaging
stuff, so some arguments may already have been made in the past.

On Fri, 2020-08-07 at 12:32 -1000, Paul Spooren wrote:
> Hi team,
> 
> currently exist two different ideas on when to raise the PKG_RELEASE
> of a package.
> 
> * When functional things change
>      For example, a OpenWrt specific patch is added
> 
> * When anything inside the packages ipk file changes
>      Includes patch and so called "cosmetic" changes outside the 
> Makefile, e.g. replace tabs with spaces.
> 
> While one could argue that following the first approach lowers the 
> number of non functional updates via `opkg`, it results in packages
> with different checksums. To keep track of what is reproducible and
> what not, it is very helpful to see changes in PKG_RELEASE. If not,
> two seemingly same packages (version/release) have different
> checksums.

Looking at other distros (Debian [1], Fedora [2]), it appears to be
common to reset the equivalent of PGK_RELEASE for every upstream
version bump. In OpenWrt it appears to mean [3] "our version since the
dawn of times" instead of "our version of this upstream release".

I feel that having to bump PKG_RELEASE for each and every commit on a
package, wouldn't be a good idea:
 * It adds an 'unrelated' change to the patch. PGK_RELEASE should be
   for keeping track of package versions, not so much for keeping track
   of source versions.
 * It will probably require maintainers to ask people to bump
   PGK_RELEASE in their patches over and over again.


> The frequent package updates are likely to happen only when using 
> snapshots, which receives a new firmware on a daily basis anyway.

Could snapshot builds use automatic package versioning? This would make
sure that not every single patch needs to bump PGK_RELEASE.
For example:
	1.2.0-1.snapshotXYZ

To make sure that version numbers only ever increase, the snapshot
version XYZ could be a source timestamp (for that package), or the
number of commits in that package. One argument against the latter, is
that the package version number would then be related to a commit in a
non-obvious way.
Fedora for example, uses a DATE.REVISION format for snapshot versions.
So their snapshot packages (for that day) may not sort correctly, but
will in any case point to a specific commit.

If the commit history between a release build and snapshot build is the
same, you may want both to have the same package version. So that might
be a special case where you don't add a snapshot version tag. Unless
you don't mind two package versions pointing to the same code version.
The latter would, in my opinion, be less of an issue than a single
package version being used for multiple source versions.

> Please share your thoughts. If there are no strong arguments against 
> bumping the PKG_RELEASE on anything that changes the resulting
> package content, I'd like to make that a policy.

[1] https://readme.phys.ethz.ch/documentation/debian_version_numbers/
[2] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
[3] commit 9c170cb92f4fbb316592c11567a080eb3f6a1fc3

--
Best,
Sander