4 ms·

Is the purpose of this project just to guarantee that bug fixes will be supported with projects? For example, I use martini, negroni, gorm and mgo on a daily ba

Is the purpose of this project just to guarantee that bug fixes will be supported with projects? For example, I use martini, negroni, gorm and mgo on a daily basis. If I switch to your repos, is it that there are no concerns that the repo will ever disappear, or if there are critical bugs you will help fix them if the project developer disappears? I think the issue I can't get my head wrapped around is, at what point does your service become relevant? 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?

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.
0xdeadbeefbabe 12y ago
> no concerns that the repo will ever disappear Why say that? Are the bits rotting? Does your build process involve deleting dependencies? Is your disk lossy?
- dougbarrett 12y ago
  I have found that when I am deploying to production, when I pull the source to compile and run "go get" then the version of the packages pulled are different than what I was working with locally. One example is the martini oauth2 library changed the way you configure it, so on production it broke when trying to take it live, but it worked fine on development. It wasn't until I ran "go get -u" that I noticed all my applications using the martini oauth2 package were now broken. If this can fix that by checking to see if there are breaking changes and place them on a different major branch, that would be a nice feature. I realize my build process could be better, and when I believe go 1.5 comes out I can compile native binaries on my dev machine to be deployed, but it was a pain nonetheless.
  - 0xdeadbeefbabe 12y ago
    Why can't you compile native binaries on your dev machine?

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.

0xdeadbeefbabe 12y ago

> no concerns that the repo will ever disappear Why say that? Are the bits rotting? Does your build process involve deleting dependencies? Is your disk lossy?

dougbarrett 12y ago
I have found that when I am deploying to production, when I pull the source to compile and run "go get" then the version of the packages pulled are different than what I was working with locally. One example is the martini oauth2 library changed the way you configure it, so on production it broke when trying to take it live, but it worked fine on development. It wasn't until I ran "go get -u" that I noticed all my applications using the martini oauth2 package were now broken. If this can fix that by checking to see if there are breaking changes and place them on a different major branch, that would be a nice feature. I realize my build process could be better, and when I believe go 1.5 comes out I can compile native binaries on my dev machine to be deployed, but it was a pain nonetheless.
- 0xdeadbeefbabe 12y ago
  Why can't you compile native binaries on your dev machine?