Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

On 12/21/24 22:06, Michael Sweet wrote:
  > We might as well.  However, you should probably also document how you'll 
manage the versioning since there are so many other components that get packaged 
with CUPS to make a working snap...  Doing MAJOR.MINOR.PATCH.BUILD versioning is 
probably sufficient for the snap versioning but it would be nice for users to be 
able to easily get a list of the bundled components and their versions as well.

The versioning is the same as distribution do when the package upstream 
software. They take the upstream release number and add an integer number 
separated by a dash, the package release number:

CUPS 2.4.12-1

When a new release of the package is done because of a new upstream release 
being used, the new upstream release number is used and the package release 
number is reset to 1.

When a new release of the package is done due to any other change, like a bug 
fix in packaging, a backport of a selected upstream (security) bug fix, ... the 
package release number gets bumped.

So it is practically the same as you suggest.

In our case with the CUPS Snap and also the CUPS Rock, we do practically the 
same, and as the principal upstream component of these packages is CUPS, CUPS is 
the donor of the upstream release number, so we have always the upstream release 
number of the CUPS in use before the dash. On any other change, including 
updates of the upstream releases of any of the other included upstream 
components, like Ghostscript for example, we bump the package release number.

The Snap and the Rock have some maintenance automation:

- Update automation: Every 24 hours a GitHub workflow checks whether any of the 
upstream components has issued a new release. If so, the instruction file for 
building the package (snapcraft.yaml, rockcraft.yaml) gets updated to use the 
new release for the package build and the updated file gets pushed into the GIT 
repository.

- Versioning automation: On each commit, both manual commits and commits done by 
the update automation, the version number is updated. If the commit has updated 
to using a new upstream release of the principal component (CUPS in our case), 
the upstream release number is updated appropriately and the package release 
number is reset to 1. On any other change, the package release number is bumped. 
The new version number is then put into the instruction file and the instruction 
file committed. After that the auto builds for the Snap Store and the DockerHub 
are triggered. So this way the auto-uploaded packages are clearly versioned.

The GitHub workflows for that are currently done by the Snap maintenance GitHub 
action of the Ubuntu Desktop Team at Canonical:

     https://github.com/ubuntu/desktop-snaps

It is planned to merge this action with the one of the Snapcrafters, a volunteer 
organization snapping applications:

     https://github.com/snapcrafters/ci

For an overview of component versions we should perhaps do a CI automation to 
keep a list in README.md updated. This could be added to the mentioned GitHub 
actions or its merger.

One would need to mark a spot in README.md, for example by a headline like

## Included components

and the automation should take all the version numbers which are under 
observation by the update automation. The update automation could actually do 
this step of generating the list and then not only update the package build 
instruction files for using the new upstream versions but also update README.med 
to have the current component version list.

So README.md will contain:

## Included components
- CUPS 2.4.12
- Ghostscript 10.04.1
- libcupsfilters 2.1.0
- libppd 2.1.0
- cups-filters 2.1.0
- ...

Rudra, Soumyadeep, could you add this automation?

I think, this way we will have a user-friendly and easy-to-maintain solution.

    Till