sql-migrate
sql-migrate copied to clipboard
rubenv
release tags pls
Tagging stable version makes package management easier. Could you please add that to your project?
Thanks!
@Plamen25 that's really not how it's usually done in Go projects. Consider master as stable.
@rubenv http://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases
I know this isn't how many go projects handle things, however, software development across every language has shown the value of versioning. As a user, I don't know when you make a change that is truly breaking vs security vs new feature that won't affect me unless I use it. Coming from Ruby, those are important details, and when the Ruby community really adopted semver, things became much more stable. Right now, the lack of versioning is honestly one of the biggest headaches for us when developing with Go, and things like Mr. Cheney's post make it clear to me that we aren't the only ones with that issue.
Yeah well, coming from the Node.JS side of things, I respectfully disagree with Mr. Cheney.
Now, before we get into philosophical musings, let's consider this: sql-migrate is very stable and thus barely moving. I'm not intent on making big changes either, so things will stay stable.
Nevertheless, if you want absolute certainty that things will never break for you, just vendor it.
I guess to each their own, however, I saw the same issues in Node that I see in Go, and I saw the same issues in Ruby before the community adopted semver. It's one of the most frustrating parts of developing in both languages. Node has been moving towards versioning for a while, and I think it's only going to be a matter of time until it becomes a standard part of Go, as it has with nearly every language in common usage.
We already are vendoring, however, that really doesn't solve the problem as when things actually do change, we can't be certain that taking a change won't break our usage of the library without spending extra time validating the changes.
when things actually do change, we can't be certain that taking a change won't break our usage of the library without spending extra time validating the changes.
Semver doesn't really help you there. In theory it would, but seeing how frequently it causes trouble in the Node.JS community due to being incorrectly applied, I'd say you still want to validate your changes anyway. You'd be foolish to do otherwise.
Now, my main reason why I don't feel like starting complicated release patterns is because it causes real pain. If you're a node user, have a look at how many conflicting versions of graceful-fs are used in any combination of dependencies.
Once you start introducing multiple release branches, you start introducing potentially incompatible versions, which turns into a much greater pain.
I applaud the Go maintainers for not blindly going down the same path as other ecosystems. Semver may solve problems but it also causes many others. Until a generally accepted better solution emerges, I'll be sticking to what is common in the Go ecosystem: keep it stable. When things do change/break (unlikely), you'll have the option of vendoring an older version.
What I certainly will not do is maintain older parallel branches, so semver will not help you out: either you keep up with change or you stick with the older version.
While I agree with @rubenv's point of view on this matter, I do think there is a middle ground.
The argument against SemVer to require the author to maintain multiple versions is a false cause. You can still work the same way as you do now, in terms of support. But as soon as you merge back, just consider the impact of the change. Was it major or minor, and bump the version respectively. Sticking to SemVer doesn't mandate the author to maintain any version branch, it's merely an indicator of change impact significance.
While it doesn't require much extra from the author's point of view, it does add value to the users of the library.
-- 2 cents.
One thing that is related to this that I was looking for when I arrived here, was the GH Releases so that the binary can be downloaded and the end user doesn't have to install Golang just to get the thing in the first place. It kind of feels a bit backwards to me to have this awesome language which compiles into a single binary with no external dependencies (like dotnet, java et al) but we then say a user has to install golang!
Over on corcel we use Travis to kick of a build using gox for every stable build which is then published to GH as a release using ghr, then the user can just download the binary for the platform they are using.
