Don't modify tags!

[Kubuxu]

Hi,
the badger is great KV-store, it really is, but I have to say after two build breaking event I'm getting tired by it.

The first one was the removal of the original 2.0.0-rc.2. Then you've pushed master to it (that was incompatible).
Now, again, you modified v2.0.0-rc2 to point to #896, which again breaks our builds (and builds for a lot of people who depend on us).

Please, stop modifying tags. All of this could have been avoided by just pushing v2.0.0-rc3 and -rc4.

What is even worst, nobody should be using v2.0.0-x tags from this repo.
By messing with them, you've polluted the namespace at proxy.golang.com which will be default in next release of Go (1.13). I challenge you to show me a go.mod file that uses tags for depending on badger and builds with both:

go build .

and

GOPROXY='https://proxy.golang.org` go build .

---

Characteristic builds errors:

 missing github.com/dgraph-io/badger/go.mod and .../v2/go.mod at revision v2.0.0-rc2

go: github.com/dgraph-io/badger@v2.0.0-rc.2+incompatible: go.mod has post-v2 module path "github.com/dgraph-io/badger/v2" at revision v2.0.0-rc.2
go: error loading module requirements

[campoy]

Hi there,

First of all apologies for the inconvenience. We have not published any version of Badger for a while and getting the repo back in shape for v2 is proving harder than we expected.

I personally deleted this tag because there had never been any v2.0.0-rc.1 at all, so the tag itself didn't really make sense from a semantic versioning point of view. We quickly realized with #886 that some (ipfs-go) depended on this mysterious tag so we put it back on but clearly on the wrong commit.

I'm curious about how you ended up depending on this tag? Was it an automated choice made by your dependency management tool? Was there any other reasoning behind?
Also, could you point me to what commit hash that tag pointed to?

Again, I am very sorry for the inconvenience. We promise this won't happen again.

[Kubuxu]

Hi, It was an automatic choice made by Go when doing: go get github.com/dgraph-io/badger@latest.

I think it was pointing to https://github.com/Kubuxu/badger/releases/tag/v2.0-rc1

[campoy]

Oh, that's bad indeed because that's actually really far from being the latest tag.

I will be tagging a v2.0.0-rc3 later today which points to the right commit and will be seen as latest, but in the meantime, I'd like to provide a fix.

I'm wondering whether it's better to modify the tag once more and just set it back to what it was pointing to, or if that could cause even more issues for those depending on that tag.

You could also use v1.5.5 which is the actual version that contains around the same commits as v2.0-rc1.

[campoy]

OK, I've decided to leave this tag as is.

If you need to go back to what the code looked like before any backwards incompatible change was made I recommend using v1.5.5 which is the actual latest release we've done.

v1.6.0 will be coming up soon, followed by v2.0.0 (and their corresponding rcX).

We will directly jump to v2.0.0-rc3 to avoid confusion with the existing rc2 and rc.2 (yes, they both exist).

Again, sorry for the inconvenience, it won't happen again.

[brandonwestcott]

Sorry to jump in late here after this is already closed, but our team is also running into this. As far as I can tell, leaving the tag pinned as is really doesn't help anyone. Those of use who are using this renegade tag (largely the ipfs community) have chains of projects depending on that tag at the original commit. Our team did start the process of changing to v1.5.5, but there are a couple of interface changes that make this more than find and replace in go.mod.

That being said, I understand that pointing to the old tag breaks semver, but that was the state of the repo earlier this week. As soon as v2.0.0-rc3 is released, I doubt anyone coming in will care about the rc2 tags. If thats a concern, maybe consider bumping the semver and skipping v2.0.0 all together.

Now, I'm not sure what effects changing the tag back will have on proxy.golang.org, but it doesn't seem like it can get any worse than the broken state it's in right now.

And I second what @Kubuxu said, badger itself is truly awesome 👍

[campoy]

We will not skip v2.0.0, since it would just make it more confusing for everyone in the future.

If the consensus is to point v2.0.0-rc.2 back to that old comit, I'm happy doing so but that might cause extra breakages for others.

Please @Kubuxu and @brandonwestcott, could you assess whether that would help you?

[Kubuxu]

Let's not mangle the tags anymore, what is done is done. I think it will be just worst if we keep poking at it.

GOPROXY is a workaround we can use for the moment.
I would suggest releasing -rc3 just so there is a fresh tag with all the code in a stable state between github and proxy.golang.org.

[campoy]

I just released a new version v1.6.0-rc1 which corresponds to the old v2.0.0-rc2.

Also sent PR ipfs/go-ds-badger#65 to ipfs to fix their build issues.