Could you create a tag or a release please?

[mjdavies]

Hi there

Loving the software!!

Any chance you could create a tag or a release version so we can stipulate what version to install with govendor?

So we could do something like this?

govendor get github.com/getsentry/raven-go@v=1.0

https://github.com/kardianos/govendor

We're currently pulling down master so at the mercy of any changes to master.

Thanks in advance

Matt

[akshayjshah]

As a whole, the Go community is moving to tagged releases. It'd be very helpful if this package did the same.

[mattrobenolt]

I'm going to say I am absolutely a +1 to this because I've almost literally gotten to a feature freeze because I'm afraid of breaking master.

I've also personally been out of the loop from the greater Go ecosystem/community, so I'm not sure what the community has come up with to solve this.

Is there something built into stdlib yet to support versioning, or will go get still always just get master? Is http://labix.org/gopkg.in still a thing people use? I want to make sure we adopt something that everyone is moving towards which will allow us to move faster here.

So if I can get some guidance, and ideally, someone to help own this process and make sure we're doing things correctly, that'd be super useful.

[akshayjshah]

Excellent! We're all on the same page, then.

The community has nearly unanimously opted to manage releases via semver version control tags, so releasing raven-go is as simple as pushing a v1.0.0 tag. GitHub releases are a convenient way to do this. gopkg.in and similar tools are generally out of favor.

There are a bunch of different tools right now to actually work with these tagged releases, but all the current favorites support semver-tagged releases. As a project maintainer, you don't need to care too much which tools your customers use. The Go team has put some official backing behind the dep tool, which should mostly unify the community once it's complete. It may or may not become part of the standard go tool.

You're in a tough spot as a project maintainer, since all your current users are pinned to the tip of master and will immediately break if you introduce any changes (even if you push those changes under a v2.0.0 tag). The kindest thing for your existing users is to not make any backward-incompatible changes to this repository. Instead, create another repository that uses tagged releases from day one. You should probably still tag a v1.0.0 here, just to communicate that you're not planning breaking changes.

[mattrobenolt]

The community has nearly unanimously opted to manage releases via semver version control tags, so releasing raven-go is as simple as pushing a v1.0.0 tag. GitHub releases are a convenient way to do this. gopkg.in and similar tools are generally out of favor.

Yeah, definitely familiar with general best practices around releases and semver, and that's not a problem as long as the tooling is prepared to accommodate.

There are a bunch of different tools right now to actually work with these tagged releases, but all the current favorites support semver-tagged releases. As a project maintainer, you don't need to care too much which tools your customers use. The Go team has put some official backing behind the dep tool, which should mostly unify the community once it's complete. It may or may not become part of the standard go tool.

I'll do a bit of research here, since we also maintain documentation for our users, and we current say go get github.com/getsentry/raven-go as the installation step. So we'll need to adopt something ourselves to recommend. Which is where things get a bit problematic when there's not something currently in stdlib. Since it means our installation instructions become fragmented or opinionated on what we think is best.

You're in a tough spot as a project maintainer, since all your current users are pinned to the tip of master and will immediately break if you introduce any changes (even if you push those changes under a v2.0.0 tag). The kindest thing for your existing users is to not make any backward-incompatible changes to this repository. Instead, create another repository that uses tagged releases from day one.

This is least likely to happen. I think I'd rather tear off the bandaid, tag a current release, and update our documentation to start using tagged releases and if a few people hit snags in the meantime, they can update to follow new conventions.

[akshayjshah]

Sounds great - really appreciate the quick response, too.

If you're going to recommend some semver-aware dependency manager, you may want to start by evaluating dep. The manifest format (which you'd use to declare the versions of your dependencies that you need) is stable, and it's definitely where the community is heading.

Tearing off the bandaid works for me :) Would you mind tagging a v1.0.0 soon? It won't invalidate any of your current instructions and won't affect any existing users.

[akshayjshah]

Hi friends (particularly @mattrobenolt) - it's been a month, anything the community can do to help get this done?

[evq]

Hey all! A few more months have gone by, just wanted to :+1: this issue.

@mattrobenolt if I'm reading the discussion correctly I think you had suggested that you would prefer to tag v1.0.0 and update instructions to move to a tagged workflow in one step.

Are you open to just tagging a pre-1.0 release now with no instructions update? (e.g. v0.9.0 or similar) This way those who want to start using a tagged release can, existing users can work off master, and once you have the documentation updates / suggested install strategy ready you can tag a v1.0.0.

[macabot]

Hey,

Are there any plans to resolve this issue? Let us know if there is anything we could do to get this done.

[mattrobenolt]

When this stuff is released, I will be keen on adopting this: https://groups.google.com/forum/#!msg/golang-dev/a5PqQuBljF4/61QK4JdtBgAJ

I've used dep in the past, and I've followed along with vgo, though I haven't used it. So excited to play with this when it's a bit more stable since it's being mainlined into go itself.

[akshayjshah]

Agreed - I'm very excited about modules too.

That said, I don't think that the ask here changes at all. Both Go's upcoming modules and virtually all of today's widely-used tools use source control tags to fetch code at a particular version. Since the current import path won't need to change for a v1 (or a v0, if you think the current code is a prototype), tagging today's code is the first step. None of your onboarding docs need to change immediately either.

[kamilogorek]

Outdated, we are using tags now - https://github.com/getsentry/raven-go/releases