I’ve just found this issue https://github.com/campoy/flappy-gopher/issues/9.

This means that gopkg.in won’t really help with versioning, because optional packages are still importing original "github.com/veandco/go-sdl2/sdl" instead of "gopkg.in/veandco/go-sdl2.v0/sdl".

This makes it pretty much pointless.

I’m currently working on CHANGELOG.md. Found this more or less popular standard Keep a Changelog.

Things to point out:

1. Rename all tags to adhere to Semantic Versioning. v0.3.0 instead of v0.3, v0.2.0 instead of v0.2 and so on.
2. Each version has a link to compare it to the previous one. Example https://github.com/veandco/go-sdl2/compare/v0.2...v0.3. Won’t work with whats written lower because of the difference in the tag names.
3. Same info will be added to the release notes of each version.
4. I decided not to mention changes in the sdl examples.
5. Some changes are squashed into one line, if there were several issue links they are comma separated in the parenthesis:

• sdl/render: Add Renderer.GetLogicalSize(), Texture.UpdateYUV() (#264).

---

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

Unreleased

// TODO

0.3.0 - 2018-05-07

// TODO

0.2.0 - 2017-11-01

Added

• sdl/endian: Add BYTEORDER.
• sdl/hints: Add HintCallback type and AddHintCallback(), DelHintCallback() functions.
• sdl/keyboard: Add GetModState() (#230).
• sdl/pixels: Add PIXELFORMAT_RGBA32, PIXELFORMAT_ARGB32, PIXELFORMAT_BGRA32, PIXELFORMAT_ABGR32.
• sdl/render: Add Renderer.GetLogicalSize(), Texture.UpdateYUV() (#264).

Changed

• Rename packages from sdl_mixer, sdl_image, sdl_ttf to img, mix, ttf.
• gfx: Rename GFXPrimitiveSetFont() to SetFont().
• gfx: Rename GFXPrimitivesSetFontRotation() to SetFontRotation().
• mix/sdl_mixer: Change QuickLoad_WAV(mem unsafe.Pointer) (*Chunk, error) to QuickLoad_WAV(mem []byte) (*Chunk, error).
• sdl/joystick: Rename Update() to JoystickUpdate().
• sdl/render: Change Renderer.GetRendererInfo(info *RendererInfo) error to Renderer.GetInfo() (RendererInfo, error).
• sdl/render: Change Texture.Lock(rect *Rect, pixels *unsafe.Pointer, pitch *int) error to Texture.Lock(rect *Rect) ([]byte, int, error).
• sdl/render: Change Texture.Update(rect *Rect, pixels unsafe.Pointer, pitch int) error to Texture.Update(rect *Rect, pixels []byte, pitch int) error.
• sdl/render: Rename Renderer.GetRendererOutputSize() to Renderer.GetOutputSize().

Fixed

• gfx: Fix GetFramecount() to call SDL_getFramecount() instead of SDL_getFramerate (#258).
• gfx: Fix SetFont() segfault when passed a nil font data.
• gfx: Fix min() function used in many gfx calculations.

[0.1.0] - 2017-06-01

I’ve looked in other alternatives and found that there will be and official Go solution to versioning, currently known as vgo.

https://github.com/golang/proposal/blob/master/design/24301-versioned-go.md https://github.com/golang/go/wiki/vgo https://research.swtch.com/vgo https://www.youtube.com/watch?v=F8nrpe0XWRg

$ vgo get rsc.io/quote@latest  # default
$ vgo get rsc.io/quote@v1.3.0
$ vgo get rsc.io/quote@'<v1.6' # finds v1.5.2

There will be some compatibility bits for vgo in Go 1.11 (August 2018), nothing major. Though Youtube video description states:

Go 1.11 will add opt-in support for package versions.

This twit states that vgo might be merged into 1.12: https://twitter.com/bradfitz/status/991674185612054529

The good thing is that they use tags for it to work. So what we’ve discussed earlier is compatible with vgo.

They propose the following package structures:

1. Have one branch with folders for each major version: go-sdl2, go-sdl2/v2 and so on. Each directory contains go.mod file with package version and its dependencies version.

module "my/thing"
require (
	"new/thing" v2.3.4
	"old/thing" v1.2.3
)
exclude "old/thing" v1.2.3
replace "bad/thing" v1.4.5 => "good/thing" v1.4.5

1. Have separate branches for each version: master, v2, v3 and so on. Each branch root dir with go.mod file.

Both solutions are good if old versions are kept alive with security or feature patches. In our case one master branch with version tags is enough.

We might need to add go.mod file later on, once this is a part Go.

There is also this:

Preparing New Versions (go release) We want to encourage authors to issue tagged releases of their modules, so we need to make that as easy as possible. We intend to add a go release command that can take care of as much of the bookkeeping as needed. For example, it might:

• Check for backwards-incompatible type changes, compared to the previous release. We run a check like this when working on the Go standard library, and it is very helpful.

• Suggest whether this release should be a new point release or a new minor release (because there’s new API or because many lines of code have changed). Or perhaps always suggest a new minor release unless the author asks for a point release, to keep a potential go get -p useful.

• Scan all source files in the module, even ones that aren’t normally built, to make sure that all imports can be satisfied by the requirements listed in go.mod. Referring back to the example in the download section, this check would make sure that logrus’s go.mod lists x/sys.

As new best practices for releases arise, we can add them to go release so that authors always only have one step to check whether their module is ready for a new release.