search

LorenzoBettini / edelta

An Xtext DSL for EMF metamodels refactoring and migration
12 stars 6 forks source link

Non-Standard Tag Format #509

Closed benmss closed 3 weeks ago

benmss commented 3 weeks ago

Hello,

On behalf of the Macaron team I would like to point out the non-standard composition of the tags within the Edelta repository. This has been detected by our tool during its analyses.

One of the features of Macaron is to find the commit that matches an artefact given in PackageURL (PURL) form for the purpose of Supply Chain Security Analysis. To accomplish this, Macaron looks at the tags within a repository and finds the one that best matches the artefact's name and version. Due to the automated nature of this process, significant deviations from the norm in terms of tag composition can prevent a match from being found.

In this case, the non-standard tag composition refers to the date-like number that appears after the artefact versions within the tags of this repository. As these are not present in the released version identifiers, and could themselves be considered a version number (albeit a long one), this is a less than ideal addition.

For example, with the PURL of: pkg:maven/io.github.lorenzobettini.edelta/edelta.target@3.5.0 We have the tag: v3.5.0.202407111254 which has the problematic suffix 202407111254.

A fix to accommodate this format is already being worked on within Macaron; however, I would still like to suggest a change in your tag scheme moving forwards. Firstly, I feel it necessary to mention that the commit a tag is associated with includes a timestamp, as seen here: 245d29e. Then, if a timestamp as part of the tag is still desired, I suggest the following:

  1. Use a different separator than used for the version identifier. E.g. v3.5.0-2024...
  2. Include a textual component before the timestamp to help differentiate it from the version. E.g. v3.5.0-d2024... or v3.5.0-t2024... etc.
LorenzoBettini commented 3 weeks ago

To be honest, I don't understand the issue, so I'm closing it. From my side, everything is generated with the right tools.

behnazh-w commented 3 weeks ago

I’d like to provide additional information to clarify the issue.

One example Maven artifact generated from the source code in this repository is edelta.lib@3.0.0. Users of this package need to review the source code for supply chain security compliance. Git tags can be used to link the artifact back to the source code, and tools like Macaron can automate the security analysis process.

Regarding the tags in this repository, a timestamp is included in the tag name. According to semantic versioning, this should be treated as a distinct version. Instead, you could have used a + sign to add metadata, as recommended by the semantic versioning guidelines here. This enhanced software engineering practice would significantly assist open source software users in utilizing automated tools like Macaron for security analysis.

LorenzoBettini commented 3 weeks ago

In Eclipse packages, we use that convention, so I still don't understand your concerns

behnazh-w commented 3 weeks ago

It would have been helpful if you could provide a reference to the guidelines for Eclipse packages. I assume you're referring to the qualifier segment in the versioning documentation here. The documentation states:

The Tycho build system automatically adds the timestamp as a replacement for the qualifier segment.

For example, if org.eclipse.core.variables specifies 3.6.300.3.12.0.qualifier, the final version would appear as 3.6.300.v20231214-1012, where v20231214-1012 indicates the timestamp of when the plugin was built.

Based on this example, the timestamp is prefixed with a v, which differs from the tags created in this repository, such as:

It should instead be formatted as:

This prefix helps tools distinguish the qualifier as metadata rather than part of the version itself.

That said, we are only requesting corrections to the tags in this repository, not the package versions. The package versions are correct and adhere to semantic versioning.

LorenzoBettini commented 3 weeks ago

So it's only a problem with the tag in GitHub repository, not with the version for the jars in the eclipse update site, isn't it?

behnazh-w commented 3 weeks ago

So it's only a problem with the tag in GitHub repository, not with the version for the jars in the eclipse update site, isn't it?

Yes, that's correct. Only the GitHub tags need to change.

LorenzoBettini commented 3 weeks ago

Ok, when I create the next releases I'll pay attention