It’s time for the dep roundup!

News and Such

We’ve hit our first big roadmap milestone - stabilizing Gopkg.toml and Gopkg.lock ! From this point forward, we guarantee that all changes to those files will be backwards-compatible. It’s now officially recommended to commit both of those files into your repository. The meta PR also breaks existing files, of course, but it also has reasonably straightforward instructions for manually converting them.

Ordinarily I avoid releases on Fridays, but I think the opposite approach makes more sense here. Even though we’ve warned people of this impending change, and not to rely seriously on dep yet, they inevitably will. By releasing over a weekend, there’s a better chance of individual/hobbyist projects poking at it first, which may give a bit of a smoother ride.

One of the things that delayed hitting this release was a conversation on the go-package-management google group. @zombiezen and @rakyll raised some entirely reasonable questions about how, in a dep world, they might release a new, backwards-incompatible major version of golang.org/x/oauth2, but facilitate incremental refactoring by providing shims between the two major versions.

We haven’t come to a good answer yet. (I’m not worried - I have a guess about what a workable solution will look like.) But these were reasonable questions, and we had just zero documentation around issues of project lifecycle maintenance. Because metadata file stabilization means that growth of the new Go package ecosystem has begun, it seemed rather important to have at least some basic guidance in place.

So, I whipped out some new FAQ entries. These are just a scant beginning of the work to be done - many years of conventional wisdom about release practices in Go are now poised for change (though not too much!). I hope to see a lot of conversations about best practices emerging in the coming weeks and months.

With that roadmap item out of the way, the next thing on the roadmap is implementing and stabilizing the command set. Work’s already been proceeding quietly here for a while - hopefully we’ll move through it quickly!

Community Attention Needed!

In past updates, I’ve used this section to pick out some specific issues that need help. But it doesn’t seem to have been particularly effective - and besides, we have a label for that. So, I’m going to change it up.

Instead of focusing on specific tickets that a lot of attention from a small number of people, I’m going to highlight things that are more suitable for a little attention from a lot of people. And not so much “things” as “thing” - just one focus area, per week.

This week, with the files stabilized and the tool safe for long-term use, the focus area is pretty clear: I’d love to see folks post issues to the dep queue with their questions about how dep should be used to fulfill existing use cases and workflows. It’s fine - even preferred - for such issues to be more discussion oriented than the more typical “feature plz” or “ugh bugs”.

That should go something like this:

Grab dep - go get -u github.com/golang/dep/cmd/dep Try converting some of your projects Poke at dep until you have some questions about how it’ll work for the way you ship Go code Give a quick check through the issue queue, and if you don’t see anything similar, post an issue with these questions!

Here’s an example: we’re paying close attention to dep ’s utility for Kubernetes, as it’s a good high-water mark for the complexity and scale the tool must handle. This week, @sttts opened a PR experimenting with some changes to mimic Kubernetes’ “staging” system.

Now, Kubernetes is an outlier, and these particular changes are unlikely to make it into dep . But that’s fine! We still learn a lot by seeing these examples. Just, don’t overthink it - if it’s at all unclear how you’d accomplish your goals with dep , then bring us an unvarnished description of your workflow, and we’ll figure it out.

Stuff We’ve 🚢ed

The pace of pull requests continues to run high, so I’m gonna focus on the more user-visible items: