Preface
Recently there has been number of conversations about semver and packages doing releases, both here and and elsewhere. I think releasing software is generally a good idea and that semver is a reasonable standard. I’d like to understand the story both today and a potential vision for tomorrow, not just how I do things, but others go users as well. I’m not interested in how other languages do them on this thread. Thanks.
Questions
- (today) Right now, what is your process for managing third party packages? I don’t mean “I use gb-vendor.” I mean a more complete description like “I first I get a package locally and try it out, then I use gb-vendor to copy it into my vendor/src dir which also notes the revision hash.”.
- (today) What do you feel is awkward or non-optimal about your current workflow?
- (tomorrow) If every package you used had up-to-date releases that all used semver, how would you envision your process would be different? Can you imagine having certain commands that would make factor X better for you?
Motivation
I understand how I do things. But I constantly need to understand how others do things today and how other might want to do things tomorrow. I want to get out of this 1) a better context for release and semver conversations and 2) insight to help me better implement remote package behavior for the tool I maintain, github.com/kardianos/vendor and the spec I currate github.com/kardianos/vendor-spec .
Example
This is my own response.
- Currently today all my packages, commands, and projects are in GOPATH. I use “go build” for my build tool. I use “go get -u” to get the latest version into GOPATH. For larger projects and commands I then copy the third party packages, package by package (not by tree or repo) locally using
govendor addorgovendor update. I review the diffs and test with those packages in the project vendor folder. For stand alone packages I don’t typically copy packages locally. I have a few exceptions to that where I’m tracking an unstable upstream. As alwaysgovendorflattens any nested dependencies out for me. To date I have not “released” my packages with tags, rather I have kept them stable. When I moved from bitbucket to github I took the opportunity to update the API. - After several years, the API design for my service package showed weakness and I wanted to revisit the API design. I’m not a huge fan of adding in versions in the path, but in this case my out was moving code hosting locations. I’m fine looking at hashes for commits usually, but for major releases, I haven’t found something I’d love to do.
- I’m mostly interested in the major (API breaking) releases. I would still want to get HEAD most of the time, but I’d like HEAD to maybe have an attached version that later can be branched out and fetched from that branch. I would want this information stored in the vendor-spec probably. A user might use it to fetch a specific revision, or just the latest on the major version. I might back peddle on this depending on implementation details and change all my packages to having a version in their path.