v1.1.0 has been released. BREAKING CHANGES!

[lestrrat]

I just release jwx v1.1.0. As announced previously, there are many API changes.
The new API should be much more consistent and streamlined (especially so if you have been following this project since the pre-v1.0.0 days)

If you do not want to deal with the changes, make sure you are using go.mod with proper version specifications.

The list of changes is too big to cover in one post, but I encourage you to take a look at both the new README and the Changes file.

Thank you for those of you who helped me in the last couple of weeks while I worked on the new version.
I hope this library is useful to someone out there. Enjoy!

[knweiss]

I would like to advocate bumping the major version to 2 in such a case (following semver v2.0.0).

As you've left the unstable version range (aka major version 0) by bumping to major version 1 the Go Modules Reference compatibility requirements are pretty clear:

The major version must be incremented and the minor and patch versions must be set to zero after a backwards incompatible change is made to the module's public interface or documented functionality, for example, after a package is removed.

Also:

Major version suffixes implement the import compatibility rule: If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.

These breaking changes do not comply with the Go modules expectations. Using lestrrat-go becomes more difficult for developers.
Asking developers to stick to a specfic older version is IMHO no good advice as you e.g. couldn't ship user of those old versions even a critical fix.

Thus, the v1.1.0 release would have been nicer as a v2.0.0 release.

Then, just by looking at the version number i.e. without even reading the README or Changes files, developers would immediately expect breaking changes when the deciding to upgrade their lestrrat-go dependency. A version v1.1.0 on the other hand indicates "don't expect major changes' which is (non-obviously) wrong.

Please consider for the next releases.

[lestrrat]

theoretically I agree. but

1. we we had a nearly two month long period where we solicited comments including the version string, and nobody pointed out anything.

2. this module did not have nearly the number of visible users back then.

3. i have yet to reveive any real life "problems"

Maybe for the next release more people who use this module and feel this way would participate in the discussion while major changes are developed

[uli42]

Please reconsider this. It's against any good practice. API changes must be visible in the version string.

Besides: Once you get to see any real life problems it will be too late to do the right thing. You then must find all kind of workarounds to support people.

Keep in mind that not everybody can update to current versions immediately (e.g. for technical or policy reasons). So these problems will haunt you....

[lestrrat]

What the f, people.
I'm merely shrugging off people complaining about spilt milk two months after the fact. For an opensource code.

Only a handful of users were present for the 5 lonely years that I have been developing this library, and of course, I would have been more careful if this was used by millions.

As it is, there was hardly anybody, and nobody ever reponded to my repeated calls to check if the changes were okay.

And in such cases I WILL take the easy way out. It is not worth it to use the best and latest practices for an non existing user base.

This is a HOBBY for me, and this is opensource.

On the other hand if you participate in the development/discussions from the next time on, of course I will listen. This is all I'm saying.

[cloudkucooland]

It took me 5 minutes to update my code. I don't expect the same level of version control from projects on github as I do from other sources. I am also clued-in enough to follow projects on which my code depends so I saw this one coming.

Thanks for your work. I appreciate all you do.