vendoring and glide

[matiwinnetou]

Now that vendoring is default in golang 1.6.x and one of recommended tools these days to manage vendor dependencies is glide I would recomment to move to glide and vendoring for external dependencies.

Thoughts? @paked @EtienneBruines

[paked]

At the moment I think we can consider most of our dependencies "stable" as they are maintained by the Go team and therefore (I believe) follow backwards compatibility standards. I don't think we need to vendor until we have packages which are outside of our control (and have a risk of being non-backwards compatible).

I'm also hesitant to use any vendoring system which will break go get and it looks like glide does that.

cc: @otraore

[EtienneBruines]

Some dependencies, such as the luxengine/math, are not maintained by the Go team. However, these are mostly static - and if it fails, it's probably fixed within a few minutes/hours.

But it might hold some value for 1.0 - since it makes no sense to have 1.0 (i.e. at gopkg.in), to ensure engo is stable, but to fail because dependencies aren't.

[mewmew]

For reference, we tried something similar in Azul3D using versioned imports and after a long evaluation period decided to ditch versioning in favour of vendoring controlled by the user (not the engine).

From azul3d/engine#1 by @slimsag

• No more package versions.
  • The official way to do this by the Go team is to use vendoring. I highly approve of this approach, and it means users can get new fixes and features when they want them (rather than relying on me to release them first).
  • We will NOT try to avoid API-breaking changes. We will document these, and maybe even continue to use semver outside of our import paths, but otherwise not.
  • This means PRs that are merged will instantly be usable by users, instead of being delayed for long periods of time until the next release (sometimes months).

[paked]

@mewmew With this model the user would also be responsible for choosing which versions of our dependencies to use too?

[EtienneBruines]

@paked I would believe so.

[mewmew]

@mewmew With this model the user would also be responsible for choosing which versions of our dependencies to use too?

Indeed.

The idea is to promote development and facilitate the design of a clean API. Rather than having a lot of "// Depricated" comments scattered throughout the source code, parts which are no longer supported will be removed in favour of cleaner API. Once such API-breaking changes are introduced, the change will be documented to state which versions (e.g. Git tag v1.2) of each package that are compatible. At least, this is how I interpret the release model, @slimsag would know more.

[paked]

OK. I'm happy with this.

[paked]

Closing in favour of #334