@cbrgm what do you think about this ?

I'm available for discussions

Heyho, in general I like the idea adding the context as the first argument. I'm not sure whether we want to release a v2.0.0 version here already. I'd like to sneak in some other breaking changes such as changing the import path from github.com/cbrgm/githubevents/githubevents/ to github.com/cbrgm/githubevents as well by moving the go.mod file as well at some point.

The library is also out since quite some years at this point and I'm also sure one can write parts of the code way better nowadays using generics as well.

So tldr: I like your idea, but I think we should plan ahead a little bit and release a proper v2 with some other changes as well. :)

I also really appreciate your OTeL example here. The issue is that since the examples are not independent Go modules, the OteL dependencies will become part of this library as well which is not great. That's also a reason why we should probably update the module structure in a v2 and make each example its own Go project. :-)

Heyho, in general I like the idea adding the context as the first argument. I'm not sure whether we want to release a v2.0.0 version here already. I'd like to sneak in some other breaking changes such as changing the import path from github.com/cbrgm/githubevents/githubevents/ to github.com/cbrgm/githubevents as well by moving the go.mod file as well at some point.

The library is also out since quite some years at this point and I'm also sure one can write parts of the code way better nowadays using generics as well.

So tldr: I like your idea, but I think we should plan ahead a little bit and release a proper v2 with some other changes as well. :)

Sure i'll be glad to help, however I think that the generation is far superior to using generics here as everything is far more straightforward as a consumer.

If releasing a v2 is also scary, I can try to create handlers with context, and we can deprecate the one without. Which means lib is still compatible.

How can we plan this @cbrgm ?

I like the idea of having a context in callbacks and see the benefits. We don't need to add deprecation notices everywhere and duplicate most of the functions. I'd say then let's push for a v2 and get this PR merged then.

After this we can split the current Go module into several modules, one for each example + move the main go.mod file into the /githubevents subfolder and update the docs. We can add a note in the README to help users migrate when we release v2 with other changes. Sounds good?

I like the idea of having a context in callbacks and see the benefits. We don't need to add deprecation notices everywhere and duplicate most of the functions. I'd say then let's push for a v2 and get this PR merged then.

After this we can split the current Go module into several modules, one for each example + move the main go.mod file into the /githubevents subfolder and update the docs. We can add a note in the README to help users migrate when we release v2 with other changes. Sounds good?

Sounds like a plan, should we do everything in that issue ?

Do you want to do it ?

Hey @cbrgm

I've bumped the version to v2

I think the go.mod file should stay at the repository root level, but I've added a go module on the examples folder.

What can I do to get this version released ?

Hey, will check this on the weekend when I have some sparetime. Sorry for the slow responses.

Merging this now.