[Feature Add]: Auto-snap-versioning

[Rudra-IITM]

Auto Snap Versioning Feature:

• Extended the capabilities of the desktop-snap tool to accommodate auto snap versioning.
• Users can leverage this feature by providing a version schema as an optional input.

Version Schema Specification:

• Users have the flexibility to pass a version schema, inspired by the 're' Python library, to precisely match their snapping repository tags.
• The version schema acts as a template, allowing for the automated updating of version tags based on user-defined rules.

Optional Feature:

• The auto snap versioning feature is optional, providing users the freedom to choose whether or not to incorporate it into their workflow.
• Users can decide to include or exclude this functionality based on their specific requirements.

Prerequisites for Usage:

• To utilize the auto snap versioning feature, it is imperative that the version is explicitly defined in the snapcraft.yaml metadata of the respective project.
• This ensures that the tool has the necessary information to perform version updates in alignment with the specified schema.

[Rudra-IITM]

@sergio-costas , could you kindly review this pull request and advise on any necessary changes?

[sergio-costas]

@Rudra-IITM I'll check it this monday.

[Rudra-IITM]

@sergio-costas, any updates ??

[sergio-costas]

Exactly what does this do? Take the current version number and try to automagically extract the version format, thus avoiding to manually set the "format" token in the "version-format" field?

[Rudra-IITM]

No, the current implementation involves extracting the version information from the designated section labeled as 'adopt-info'. Subsequently, based on this information, it automatically updates the version of the primary snap. The versioning scheme comprises two components: the version number of the primary upstream component and a small integer representing releases of the snap, provided the primary upstream component remains unchanged. In the event of a new release of the primary component, the version number is incremented accordingly, with the package release number being reset to 1. Furthermore, any other modifications to the package result in an increment of the package release number by 1.

[Rudra-IITM]

@sergio-costas, I've segregated the manageYAML and Snapcraft classes into distinct files. Please review the modifications.

[tillkamppeter]

@Rudra-IITM I assume that what happens here is that every 24 hours, when the Snap repo's workflow triggers this GitHub action, it is checked for new commits and if there actually are new commits, the Snap's version is updated. This leads to an extra commit for the version number update. snapcraft.yaml always contains the current version number in its header. Am I right?

In my original version, individually added to each Snap, there are no extra commits. snapcraft.yaml does not contain the version number and the version number is determined when building the Snap, based on the version currently in the Snap Store, so it gets bumped with each build for the Snap Store (skipping on no-change rebuilds). This way the version gets bumped on every commit and not only once per day. Question on this method is whether if the build on one architecture fails and a commit to fix this is done afterwards whether after this commits all architectures will still have the same version number. If not, this would disqualify this original method and make the method of this PR preferred.

If version bump with every commit is desired one could use this GitHub action by simply adding to the trigger methods in the Snap repo's workflow that it should be also done on every commit. Then each commit would be followed by a version bump commit (attention, needs a guard against infinite recursion). The every-24-hours trigger method needs to stay, so that new upstream versions are detected also on days without commits.

[Rudra-IITM]

@tillkamppeter,
Thank you for your insight. You are correct in highlighting the important aspect of this script's behavior.

You are right at the point that this script checks for any commit in snapping repository when the github-workflow is triggered.
This will also create a new commit for version update. snapcraft.yaml should always contain version in its header.

Allow me to elaborate further on the script's functionality:

• Initially, it retrieves both the snapbuilddate of snap and gitcommitdate of the snapping repository.
• The script then evaluates whether gitcommitdate exceeds snapbuilddate, incrementing packagerelease by 1 accordingly.
• Furthermore, it monitors any new tag releases in the upstream component, updating the primary version as necessary while resetting packagerelease to 1.

[sergio-costas]

Another question: how is the version number incremented? I mean: is just the same number than in the git tag, or does it add something extra?

[Rudra-IITM]

Another question: how is the version number incremented? I mean: is just the same number than in the git tag, or does it add something extra?

The primary idea behind allowing the version-schema to be user-input lies in affording users a degree of customization regarding the version number. For instance, consider the ghostscript-printer-app. While the git tag may be labeled as 'ghostpdl-10.02.1', the version listed on the snap store appears as '10.02.1-2'. In such instances, users can specify a version schema such as '^ghostpdl-(\d+.\d+.\d+)' to isolate '10.02.1', with the package release appended as previously outlined.

[sergio-costas]

Just a little nitpick.

[sergio-costas]

Ok. Thanks!