search

ryanuber / go-license

Software licensing standardization library for Golang
MIT License
69 stars 15 forks source link

Performance + refactoring #15

Closed ryanuber closed 5 years ago

ryanuber commented 8 years ago

I've done some work refactoring things a little bit for better performance and effeciency, and along the way noticed a slew of mistakes I made in the original library. This PR patches lots of this stuff up and really simplifies the API a lot. However, I noticed mid-way through that some of these mistakes were in the public-facing API, and are actually being used. Going to let this marinate for a little bit while I think about any nicer way to preserve backwards compatibility.

Fixes #10 Fixes #11 Fixes #13 Fixes #14

dmitshur commented 8 years ago

However, I noticed mid-way through that some of these mistakes were in the public-facing API, and are actually being used.

In how many places is it being used?

I only see 3 importers at https://godoc.org/github.com/ryanuber/go-license?importers.

Can you submit PRs upstream to update their API usage to your new one, in order to not have to maintain multiple versions?

ryanuber commented 8 years ago

@shurcooL it's definitely tempting. The users I am more worried about are those who use this in private projects. A number of people have reached out to me about this project via email. It makes sense that there is use within private organizations, since juggling OSS licenses can be a huge burden if your product contains lots of them (I have dealt with this regularly in the past while working for a big company).

That said, I still am interested in deprecating the stranger parts of the API completely. I think I may still end up doing that, and leaning on vendoring for any BC needs since its now pretty core to normal Go development. Just still a bit torn since BC is something I am usually very cautious about.

dmitshur commented 8 years ago

Makes sense, thanks for explaining.

I like your idea of deprecating and relying on users to vendor this package at the version they're comfortable with using, and updating the API if they want to get latest version.

Of course, you could always create a v2 API at a different import path and maintain both packages, but that's more work and probably not worth it. I'm sure you wouldn't want to do that either. :)