Thomas Frössman

I will implement the valid version check in my client using a semver library so that the client only accepts a semver version newer than itself.

Btw. I'm getting to this item some time tomorrow in the project I'm working on (which currently is being moved to https://github.com/alkasir/alkasir ).

Btw. would you like me to contribute https://github.com/alkasir/alkasir/blob/master/pkg/upgradebin/ed25519Verifier.go to go-update?

So.. this is how I solved in my use case.. It could possibly be a pattern of interest to other people... Adding the version number to the verifier: https://github.com/alkasir/alkasir/commit/5d57cc6168f958775583a6a4be8c1d5e79d72369 And...

I think it might be caused by projects only owned by groups instead of a user, ie. no project members, only group members. .. I can try to verify that...

I'll verify soon, a bit busy atm.

I still get an error from gitlab-show-projects.. Will investigate at once.

This might be another issue, not sure. The new error is caused by an `(description)` with a nil cdr in the data which makes `(replace-regexp-in-string "\^M\\|\n" " " (assoc-default 'description...

you could also just have a `gitlab-auth.el.gpg` and load that when you require emacs-gitlab.. You don.'t need something special case functionality for this. I think you need to have this...

Have you thought about which route to go? Some if not most of the gitlab client libraries I've used has taken the path of fetching all results at once regardless...