Dep: proposal:rework approach for tool release along with Go 1.9

[dlsniper]

Hi all,

I would like to gauge the interest of this team and contributors for taking a different path in order to get this released with Go 1.9.

By the looks of the things now, there are many outstanding problems in various parts of the solution, and while I'm not saying it's an easy problem to fix, there are definitely different approaches that can be taken to solve it.

My personal interest is to get this merged as soon as possible in Go 1.9 tree and start shipping it with Go 1.9.

Why the rush you might ask?
The answer is simple:

• so that people can get used to the tool
• start migrating from their current favorite tool to this
• package / application maintainers start tagging their releases more and more
• tools like editors can start integrating with the project and provide a better user experience

The approach I would like to see is:

• move the current tool to an experimental branch
• start small and expand from there

What do I mean by start small?
Start from solving the smallest possible problem: getting the dependencies at the correct version for the user.
The process can be as simple as:

• read manifest file
• for each dependency do:
  
  
  
  • git clone dependency in vendor/
  
  
  • git checkout dependency at desired revision
  
  
  • if dependency exists and major version is different abort
  
  
  • if successful, read dependencies of the dependency, add to the list, if there's a major version conflict, abort
  
  

If this tool would then be merged into the main Go repository two things would happen:

• people could start contributing more smartness to the tool
• as the release cycle for Go 1.9 approaches there could be several options that present themselves:
  
  
  
  • continue to accept changes to it until Go 1.9 RC 1 is released (for example, could also just follow the Go release approach to do feature freeze and just bug fixing while in Beta period)
  
  
  • abort the tool and deliver it as a separate tool like now
  
  

I understand that this approach would sacrifice a lot of the features that the tool should have, but the goal of the tool should be to start getting it to be used as a stable tool, not just by people that are adventurous (and often don't read the big warning that the tool is in pre-alpha state, as it has been my experience for the past few weeks from people on Slack reacting with: Oh, I didn't knew it's not stable yet).

Must it be released along side if with Go?
That's up for debate, maybe not, maybe it can just sit in this repository, but it should be usable and have no problems at all. Currently looking at the various issues (with many panics, which is a rather unexpected behavior), it doesn't look like it will be usable any time soon and personally I can't recommend it to anyone / start working on an integration for it / contribute to it such an integration.

As such, I urge the maintainers of this project to reconsider their approach and instead of trying to solve all the problems at once and have the "best in-class" tool, have a dumb tool that just works but it gets better in time.

Thank you.

[francknouama]

+1

[adg]

As such, I urge the maintainers of this project to reconsider their approach and instead of trying to solve all the problems at once and have the "best in-class" tool, have a dumb tool that just works but it gets better in time.

We are not even close to "trying to solve all the problems at once." We have whittled down the list of requirements to a very small set of achievable features.

Furthermore, nobody is going to switch to a tool that doesn't give them some baseline feature set. If nobody switches, the effort is totally in vain.

Scope was a major part of the discussion from day one. We made a lot of careful decisions to get where we are now. We are not going to throw all that work away now.

Thanks for your suggestion.