3 ms·

Hi, StableLib is my project. Happy to answer your questions!

by dchest 12y ago

dougbarrett 12y ago
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?
crawshaw 12y ago
Looks like a great project. Maintaining a stable set of libraries for a complex project is incredibly time consuming. I would imagine many organizations would be interested in this, much like they purchase RHEL.
- dchest 12y ago
  Thank you!
grey-area 12y ago
Sounds like an interesting project, I can see it being appealing for some companies, here are some thoughts which popped into my head when reading your page: Do you have a provisional list of packages you're planning to include? How will you make money, or is this a labour of love? One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language. Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it? Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time? EDIT - oh I see you do suggest you might do this on your page lower down. Are you planning managing patches/bug fixes yourself for packages which fall into disuse?
- dchest 12y ago
  Do you have a provisional list of packages you're planning to include? I do, but it's currently not published yet. How will you make money, or is this a labour of love? Red Hat-like subscription model. I will provide support, security advisories, etc. One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language. Indeed. Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it? I didn't ask for permission, but I agree with you about involvement. The ultimate goal is to hire/sponsor as many package authors as possible :-) BTW, after doing code reviews of some packages, I already submitted a few pull requests to them, so even thought right now there are no financial contributions to package authors, there are some benefits for being included in StableLib :-) Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time? This is a great idea, thank you! Are you planning managing patches/bug fixes yourself for packages which fall into disuse? Yes.

Hi, StableLib is my project. Happy to answer your questions!

by dchest 12y ago

Hi, StableLib is my project. Happy to answer your questions!

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?

crawshaw 12y ago

Looks like a great project. Maintaining a stable set of libraries for a complex project is incredibly time consuming. I would imagine many organizations would be interested in this, much like they purchase RHEL.

dchest 12y ago
Thank you!

grey-area 12y ago

Sounds like an interesting project, I can see it being appealing for some companies, here are some thoughts which popped into my head when reading your page: Do you have a provisional list of packages you're planning to include? How will you make money, or is this a labour of love? One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language. Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it? Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time? EDIT - oh I see you do suggest you might do this on your page lower down. Are you planning managing patches/bug fixes yourself for packages which fall into disuse?

dchest 12y ago
Do you have a provisional list of packages you're planning to include? I do, but it's currently not published yet. How will you make money, or is this a labour of love? Red Hat-like subscription model. I will provide support, security advisories, etc. One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language. Indeed. Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it? I didn't ask for permission, but I agree with you about involvement. The ultimate goal is to hire/sponsor as many package authors as possible :-) BTW, after doing code reviews of some packages, I already submitted a few pull requests to them, so even thought right now there are no financial contributions to package authors, there are some benefits for being included in StableLib :-) Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time? This is a great idea, thank you! Are you planning managing patches/bug fixes yourself for packages which fall into disuse? Yes.