Release?

[mauleyzaola]

Hi @rubenv would you mind creating a release tag for this repo, so go dep users like myself have a safe checkpoint where to rollback in case anything goes bad?

For instance, I see you just pushed the changes for the latest packr deprecation, that sort of things is what I mean.

If you don't have the time to do it, please let me know so I can do it myself. Thanks.

[rubenv]

would you mind creating a release tag for this repo, so go dep users like myself have a safe checkpoint where to rollback in case anything goes bad?

Could you walk me through what exactly this would entail?

For instance, I see you just pushed the changes for the latest packr deprecation, that sort of things is what I mean.

How did that go bad?

[mauleyzaola]

Could you walk me through what exactly this would entail?

Github does that automatically for you, just go to https://github.com/rubenv/sql-migrate/releases and create a new one. More help can be found here: https://git-scm.com/book/en/v2/Git-Basics-Tagging

Or just tag it from the command line and push the tag to the repo

xxx$ git tag -a v1.1 -m 'Another release'
xxx$ git tag
v1.0
v1.1
xxx$ git push origin v1.1

How did that go bad?

Well, actually it didn't because you fixed it right away, but there is a potential risk in the future. At my current job we are using your package to integrate into the CI workflow and we use dep to handle the dependencies. Dep relays on git tags and when they are none available it uses master branch.

It would be safe for your users to be able to point (or even force) the dependency to a point in time instead of the latest version.

Hope I was clear enough and thank you for such awesome package. I love handling the migrations from within golang code, makes me more productive.

[rubenv]

Oh, nothing more than a git tag. That's good.

But to be honest, adding a tag for every commit is a pain in the ass. I'm declaring sql-migrate as finished, so there will never be a version that breaks compatibility (unless Go forces it onto us).

In the rare case that a rollback is needed, can't you just then (and only then) pin to a specific commit? It looks like this is supported in dep: https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md#revision

[rubenv]

Also, note that the packr thing wasn't cause by anything inside sql-migrate, but rather in packr (we just have an interface that mimics it, but no dependency). So we didn't break anything here: packr changed its behavior.

[mauleyzaola]

adding a tag for every commit is a pain in the ass

Lol, you don't want to do that! Usually a release contains a bunch of fixes/new features and tags a different version. It is totally up to the author.

And yes, I could point to specific commit although it is clearly an anti-pattern.

Nice you thought about it implementing an interface, but shit happens there is no bullet proof for it. We as consumers only look for the best way to keep things working on every possible scenario.

It was just a suggestion, of course your code looks stable (that's one big reason why we are using it, for starters) and it wasn't directly your fault. This lack of tagging is just something I noticed and seen in other packages. But you can do basically whatever you please.

I am closing this one, thanks for the fast response.

[rubenv]

Lol, you don't want to do that! Usually a release contains a bunch of fixes/new features and tags a different version.

Yeah, it makes sense for something that's in rapid and active development.

I'd love to keep changes to sql-migrate small and minimal. It does its job and it does it well. How about we consider it as finished?

This obviously completely goes against the trend of "newer is beter, time to rewrite!", and I'm proud of that :-)

[mauleyzaola]

@rubenv Hey, glad to see you are doing git tags now. Thanks!

[rubenv]

Sorry for delaying that so long!