Missing release & tag for 5.0.0

[jinnatar]

Version 5.0.0 is published on pypi but has no corresponding release or tag in the repo.

[sallner]

This is particularly sad, because there is no changelog and it is hard to assess, what has changed. This issue is already open for longer then a month. Can we trust the release and the release process?

[sallner]

It seems like the 5.0 release was tagged 4.5, see the diff here. v4.1.0...v4.5.0

Maybe it was intended to be a maintenance release but ended up being a major release by some accident. I would still be nice to have a correct tag and release on GitHub here.

[rohe]

Yes, an error on my side. I’m soon to release 5.1.0 will hopefully get in sync then.

…

On 8 Nov 2024, at 12:11, Steffen Allner ***@***.***> wrote: It seems like the 5.0 release was tagged 4.5, see the diff here. v4.1.0...v4.5.0 <v4.1.0...v4.5.0> Maybe it was intended to be a maintenance release but ended up being a major release by some accident. I would still be nice to have a correct tag and release on GitHub here. — Reply to this email directly, view it on GitHub <#114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYMPDXKMS5AAHUIFTGHJTZ7SL6FAVCNFSM6AAAAABPHTL2HSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRUGQZTCOBZGM>. You are receiving this because you are subscribed to this thread.

[jinnatar]

Any updates on tagging & releasing 5.0.0 and/or 5.1.0?

For context why I care, SATOSA is currently bound to >=2.1.0 which means any plain satosa[idpy_oidc_backend] install is missing a bunch of fixes it would benefit from. As of SATOSA >=8.5.0 the backend is now released and out there. I'm hesitant to propose in that repo requiring any version that isn't actually officially published so the highest I would propose is v4.5.0. Even if I did now propose 5.0.0, it would still be missing for example PR #111 since while it was merged to main (edit: I was wrong, I missed the timing by 1 day), the 5.0.0 release wasn't cut from main but from some completely different feature branch.

Long story short, I'm asking to do something along these lines:

1. If easily possible, tag v5.0.0 to the ref from which it 5.0.0 was published to pypi and add at least a stub release to GitHub. This is difficult to do for anyone on the sidelines since we can't tell what exact code was pushed to pypi without diffing the entire codebase against the tarball. If this is difficult / annoying, it may be better to just do v5.1.0 right instead.
2. Merge any changes that have already been published in 5.0.0 to main.
3. Cut the next release from main, or from a "5.1.x" release branch. I would hope to ensure PR Update OIDC id_token_signing_alg_values_supported for wider algo support #111 makes it into that release so that I can then ask SATOSA to require that version.

[jinnatar]

Based on my diffing, it seems that the GitHub release & tag v4.5.0 roughly matches the contents of the PyPi release v5.0.0 with the only src/ diff being removing src/idpyoidc/server/session/.grant.py.swp + a bunch of tests are missing. Ergo there is no exact commit from which the PyPi release was cut, but v4.5.0 is sort of close. As that was never published to PyPi, this is of course a rough estimation diffing between release artefacts vs. a source tree.

Since PyPi is immutable, the closest easy fix for the history would be to tag 475ef2a as v5.0.0 as well, and add a GitHub release for that tag. But for the future v5.1.0, it would be handy if a GitHub release, git tag and PyPi release version were all in alignment, and preferably cut it from main or a release specific branch that merges main & any necessary feature branches that are not present in main.