New release

[JohanMabille]

Hi,

Last release (2.3.0) was 2 years ago, and now that we upgraded to nlohmann_json 3.12, I think it would be nice to release a new version. It seems that there is no API breaking changes since 2.3.0; so I guess the new version should be 2.4.0. I can cut a release if nobody else can do it, but I don't know the release process (should it be a PR? a commit directly on main with only the version number updated?)

[pboettch]

There was no real release process.

What I did in the past was integrating MR which I could oversee and which didn't break the regression tests.

If that was OK, I pushed a tag to main directly.

But this was before there were package-creation CI jobs.

[LecrisUT]

The common workflow is to make a PR to consolidate and refine the changelog. There doesn't seem to be one in this project, but not opposed to adding one either manually or via towncrier or equivalent, and I can share some tips that I have gathered about these. Because of this, just tagging and publishing a release is good enough.

[pboettch]

Yeah, that's actually one principle we should follow: a pushed tag + CI-jobs should generate the release-files and the packages - nothing should be done manually (I'm getting old, and this is where I'm coming from - CI-formalisation is so much better).

If there aren't any special release CI-jobs, than at the tag will make githab create the source-package and the links on the site.

[JohanMabille]

We can use https://github.com/elgohr/Github-Release-Action to generate the Github releases with changelog when a tag is pushed. This still requires to push a tag manually. We can fully automatize that with a Github App that will run the workflow, but that requires some configuration at the org / user account level. That can be done later though.

EDIT: there we go

[LecrisUT]

I cannot find my original reference, so hope this comment is helpful enough to describe the workflow. Basically it creates and rebases a release PR where the changelog is compiled. My inspiration for that was somewhere in executablebooks but I can't find it now.

Otherwise for just creating releases from tags I recommend something dead simple: https://github.com/spglib/spglib/blob/develop/.github/workflows/release.yaml it is an extendable workflow, but for this project it can be reduced to just the last job.

[JohanMabille]

What do you think of running a script from the Github history and sorting entries by "topic" (new feature, bug fix, maintenance) that we can enforce with PR labels? I find it simpler for the contributors than asking them to add a new file for each entry in the changelog.

[LecrisUT]

That is basically .github/release.yaml workflow, perfectly fine workflow IMO. The things you would have to note is that the PR title is used for the entries so make sure you sanitize them as needed.

As for having them in a changelog, that can be done when the release is cut. There is some gh cli to do this, but it's been a while since I last looked into it.

[pboettch]

I got an email off-github telling me that the 2.4.0 release has not arrived in Conan and even on github it is not seen as a release.

Did we miss something?

[pboettch]

Hmm it seems we forgot to tag? Is this automatically done?

[LecrisUT]

Ah it was my fault, I should have reviewed more carefully

json-schema-validator/.github/workflows/release.yaml

Lines 7 to 8 in c780404

	- "v[0-9]+.[0-9]+.[0-9]+"
	- "v[0-9]+.[0-9]+.[0-9]+-rc[0-9]+"

The tag format used here does not start with v so that was never triggerred. If ignoring thr conan workflow is ok, just do the release manually this time.

[pboettch]

The fix is maybe to push a tag starting with v?

[pboettch]

No, forget what I said, there are no 'v' prefixes here...

[pboettch]

So what now? Quick and dirty: repush the tag on the new commit fixing the actions?

Or doing a new release?

[LecrisUT]

The fix is maybe to push a tag starting with v?

Preferrably not that. Sometimes it can be surprising to downstream packagers

So what now? Quick and dirty: repush the tag on the new commit fixing the actions?

Or doing a new release?

The tag is already there, so just publishing the release from github UI will be enough. It will populate the changelog for you directly so there wouldn't be a difference in the results

[pboettch]

!