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

Rudra,

Just to be clear, this is a separate README.md for the snap and not the repository's main README.md file?


> On Dec 22, 2024, at 4:23 AM, Rudra Pratap Singh <[email protected]> wrote:
> 
> Building on your suggestion, I believe implementing automation to maintain a component version list in README.md is an excellent idea. This enhancement would provide users with a transparent and up-to-date overview of the included components, making it easier to track changes and understand the current state of the package.
> Here’s how I propose approaching this:
>     • Marking the Spot in README.md:
> We can designate a specific section in the file, such as:
> <!---->
> ## Included Components
> <!---->
> 
>     • Updating the Section During Workflow Runs:
> When the workflow runs, it can update the section to something like this (and will auto update as versions are changed):
> <!---->
> ## Included Components 
> - CUPS 2.4.12 
> - Ghostscript 10.04.1 
> - libcupsfilters 2.1.0 
> <!---->
> 
> I can try implementing this either in the https://github.com/ubuntu/desktop-snaps repository or in the https://github.com/snapcrafters/ci repository once it’s included.
> Best regards,
> Rudra
> 
> On Sun, Dec 22, 2024 at 3:25 AM Till Kamppeter <[email protected]> wrote:
> 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
> 

________________________
Michael Sweet