3 ms·

> What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you? Details about versioning ar

by dchest 12y ago

> What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you? Details about versioning are still in development, but here's the rough idea: If it's a small reviewable feature that can be applied without breaking anything, then yes, it will probably go into a dot release of the package. For example, you use "github.com/dchest/siphash" package. In StableLib it's version v1.0.0 (vX.Y.Z), available via "stablelib.com/v1/crypto/siphash". Notice v1 in import path — this is the major version of the whole StableLib release (X). All version within v1.Y.Z are guaranteed to have the same API, so you can upgrade v1.0.0 to v1.0.1 or v1.1.0 and your application won't break. Now, if dchest/siphash fixes a bug, it will be releases as v1.0.1 in StableLib. If it introduces a new feature, which doesn't break API, say, additional function to calculate 128-bit hash, it will be v1.1.0 in StableLib. In general, you will be on the latest release within the major StableLib release. Sometime in the far feature we will release StableLib v2, which will break API, and will be available at stablelib.com/v2/..., so your v1 packages will still work. I'm happy to hear any suggestions.

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 ago
  A 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.

by dchest 12y ago

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 ago
A 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.