Keep codemeta.json version current

[ChristianTackeGSI]

Looking at codemeta.json, it seems that the version field ("3.2") isn't really the current version?

Can you please update it?

For FairRoot we have setup a check in the main CMakeLists.txt for this and our CI checks it: FairRootGroup/FairRoot#1441

cc: @kresan

[AnarManafov]

@ChristianTackeGSI , that's exactly the problem I see with all those "meta" file initiatives - that developers have to update them manually or by running a script. That's should be the case with current technologies.
The normal release process is as simple as pushing an annotated tag to the rep - that's it.

Alls those "meta" things should get such info on their own as they have access to the repo. It's the job of the meta-info service to collect such info. They can see releases, history, etc, via git or github API.
Why they delegate their work to us?

And yes, I will update the version. Sorry, missed it when edited the file last time.

[ChristianTackeGSI]

You could create a release tarball using some "make dist" facility and update the fields for the release tarball fully automatically.

You could then automatically upload all of this to zenodo and create a release there (zenodo has an API).

There's even some helper tools from the OSSR people for this. Maybe start here? https://gitlab.com/escape-ossr/eossr/-/blob/master/examples/CI_code_snippets/3.ex_CI_upload_ossr.md

[AnarManafov]

@ChristianTackeGSI , you didn't get my point.

First of all, I (or my CI) don't need to do all of that, as I simply call the github (gitlab) release API to release a package with all assets.
Zenodo catches this event automatically too. It works perfectly.

Note, that in the whole release procedure there is NO modification of the source tree. None of CI jobs modify the source, they rather use the current state of the tree to make the release. I even prohibit automatic modification of any file by CI jobs.

But having this meta things, I need to modify the source tree before making the release. I am jus saying, this info is already available as a meta data of the git repo. Why I should duplicate it manually (or by script)?

Honestly I don't want to spent hours discussing this. I just wanted to state, that today, all those meta-info services have all the tools (APIs) to get all the info they need without forcing developers to write nonsense files (manually and partially by scripts). It simply complicates the release process of each affected product. Instead of doing actually their job and automate.
So, they made an initiative and simply delegated the whole work on all other participants. A super cheap solution.

[dennisklein]

But having this meta things, I need to modify the source tree before making the release.

I agree that this is broken - I also refuse to do this in the FairMQ repo. For authors/contributors it is the same story, if your authoritative source it the git metadata as well.

I (or my CI) don't need to do all of that, as I simply call the github (gitlab) release API to release a package with all assets.

That's the right way. The point of discussion would be what are the attached assets. Unfortunately, github creates by default (and one cannot disable those) tarball and zip file from the git working tree content... The Zenodo server-side integration - unfortunately - picks those tarballs up. But this is broken as well, IMHO - the git working tree MAY NOT BE EQUAL to the dist tarball. (The world still relying on dist tarballs is another topic that is broken. Ideally there are only git repo clones, but that is not what many systems expect... - even Spack - as a truly modern tool without legacy - got it partially wrong, at first it makes a proper git clone and once you create a source cache they just drop the .git directory and store only the working tree :( )

I agree with Christian that the upstream project should create proper distribution tarballs as long as the world does not adopt git properly. Now, how do we get out of the situation that all the wrong workflow is currently super neatly supported and integrated with github and zenodo and all the right workflow causes upstream to write extra CI jobs...

Instead of doing a full dist tarball, I was also entertaining the idea to just generate the codemeta.json file and upload it as a second attachment to the zenodo entry. That way one could keep using the current server-side integration for the most part. But still nothing trivial. Still needs zenodo credentials in my CI, needs synchronisation to wait until zenodo entry got created...

[dennisklein]

My current feeling for the best solution is

• Upstream creates dist tarball assets attached to the github releases (besides the default created ones)
• .zenodo.json (and/or Zenodo's web interface) learns a new option to pick up those proper dist tarballs from the github release asset list.

That way upstream at least does not have to manage zenodo secrets. And dist tarballs are still a somewhat widely relied upon artifact (e.g. by many package managers), I would be willing to provide.

[dennisklein]

slight variant: Instead of a dist tarball, upstream just puts a codemeta.json as additional github release asset instead of having it inside the github auto-generated source tarball.

[AnarManafov]

slight variant: Instead of a dist tarball, upstream just puts a codemeta.json as additional github release asset instead of having it inside the github auto-generated source tarball.

@dennisklein , I like this one very much. The meta file is then can be autogenerated without adding it to the main repo tree.
This is the way.

[dennisklein]

slight variant: Instead of a dist tarball, upstream just puts a codemeta.json as additional github release asset instead of having it inside the github auto-generated source tarball.

@dennisklein , I like this one very much. The meta file is then can be autogenerated without adding it to the main repo tree. This is the way.

yes, I also like it the best so far. And OSSR/Zenodo then have to learn how to pick it up from there. Saves upstream also from having to manage zenodo secrets in the CI.

And for the codemeta.json file in the repo itself (I still gotta put some template at least somewhere, I could put master as version) and that has to be acceptable for now until OSSR/Zenodo can deal with codemeta.json as separate release asset :P

Let's see, if they accept this proposal.

[dennisklein]

	Property	Type	Description	OSSR Requirement Level
16	softwareVersion	Text	Version of the software instance.	required	Any string will be accepted, but semantically-versioned tag is recommended. See semver.org for more information on semantic versioning.

https://escape2020.pages.in2p3.fr/wp3/eossr/metadata/ossr_metadata.html#OSSR-metadata-table

I guess, for now, it will be fine to just put master as softwareVersion.