7 ms·
What's with the package versioning? http://azul3d.org/doc/versioning.html#development-versions http://azul3d.org/doc/versioning.html#development-versions v1 (l
by damian2000 12y ago
What's with the package versioning?
http://azul3d.org/doc/versioning.html#development-versions http://azul3d.org/doc/versioning.html#development-versions
v1 (latest version)
import "azul3d.org/audio.v1"
v0 (in development)
import "azul3d.org/audio.v0"
Is this normal for go packages?
- adrusi 12y agoIt's not normal, but package versioning in go is broken, so people invent their own workarounds
- mseepgood 12y agoThere is no versioning, so it can't be broken.
- AYBABTME 12y agoThat's one way of doing it. Another is to just use their github path and use vendoring tools like godep. I prefer vendoring since it doesn't rely on a 3rd party being online or existing in a year. Also it's simpler when you want to have repeatable builds, since the vendored code is usually in your repo. It's also convenient for CI/CD things, since your repo ships as a unique component. Also using versioned path like that means that a version bump means editing all your files. Across a large project, it becomes harder to manage. However, versioned path aren't incompatible with vendoring tools. So one doesn't prevent the other. FWIW, I think versioned path is also not very popular in the pseudo-contest of vendoring code/versioning path.
- slimsag 12y agoEw, don't do it by hand. You can use tools like govers to rewrite the import paths to newer versions. It's not hard to manage at all IMHO.
- slimsag 12y agoHi, author here. I wanted to let you know that I agree .v0 is strange. I see that now and it was an oversight. We're changing it from v0 to dev now instead: import "azul3d.org/audio.dev" No worries though, v0 will continue to work for backwards compatibility. Track the issue: https://github.com/azul3d/issues/issues/10 https://github.com/azul3d/issues/issues/10