3 ms·
Got it, and for the other part? I'm just wondering what makes this entirely different from github assuming that the authors don't remove the project or delete t
by dougbarrett 12y ago
Got it, and for the other part? I'm just wondering what makes this entirely different from github assuming that the authors don't remove the project or delete their account. I think I'm just unclear on what value you are adding and for current projects why I would use your repositories over the actually package developer.
I'm genuinely interested in this as a service, as I have ran into issues where packaged have API breaking changes that I'm not aware of until we pull code on the production server when we're ready to launch, but I'm just not sure if I'm clear on the intentions.
- dchest 12y agoA perfectly maintained package would look like this: - uses proper stable versioning (e.g. gopkg.in), making sure not to introduce breaking changes in the same major version - backports critical/security fixes into previous stable versions - has their code reviewed by a third party - provides notifications for critical fixes/security advisories - provides support for package users Not all packages are perfectly maintained, though (even my personal packages are not). Consider this sample of third-party packages from one of my project: github.com/boltdb/bolt github.com/dchest/cache github.com/dchest/conf github.com/dchest/validator github.com/hashicorp/logutils github.com/justinas/nosurf github.com/stretchr/graceful github.com/stretchr/pat/stop golang.org/x/crypto/bcrypt golang.org/x/crypto/blowfish golang.org/x/net/netutil If I'm having a production app running that uses these packages, I have to track all of them, making sure I don't miss some critical bug fix. StableLib will do this for you: just subscribe and you'll get notified of updates, and you will receive backported fixes, so that you can update without worrying of breaking our apps.