all: convert into a Go module about wuffs HOT 3 CLOSED

When you talk of dependencies, do you mean depending on the *.go code that make up the Wuffs compiler, or on the *.{c,h} code for the 'runtime' for built-in types like io_buffer, on the *.wuffs code that make up the Wuffs standard library, or all of that?

Regardless of the answer, "convert into a Go module" isn't free. IIUC, it would require adopting semantic versioning, which would require bumping a minor version number every time there is a breaking change, and at this point in time, I seem to be making breaking changes every week.

Or, if https://semver.org/#spec-item-4 allows "0.y.z" to mean "Anything may change at any time" then I can skip bumping the minor version number every week, but that doesn't seem to help you if I'm still making breaking changes.

Yes, it's a bumpy ride, but I did say that it's too early to expect a stable ride. Sorry.

from wuffs.

Oh, I do know that breaking changes will come at any time no matter what :) Perhaps it's not a good idea to adopt semantic versioning just yet, then.

I personally don't care if/how the Wuffs standard library is versioned. I don't even know if I can import it from my code.

What I do care about, as you say, is the Go code that makes up the compiler, as well as the "runtime".

I only suggested this because I thought you were already versioning both of those, having seen commits like wuffs gen -version=0.2.0-alpha.16. If that's a different thing, then please ignore this issue for now.

from wuffs.

The wuffs gen -version=0.2.0-alpha.16 thing affects the generated C code in the release/c directory. It's not about the Go code or the 'runtime'.

Also, the generated C code has the version explicitly in the filename: the v0.2 in wuffs-v0.2.h. The plan is to have multiple files (API versions) in that directory, so that someone who uses v0.2 won't be affected when v0.3 is eventually released, and so there's not so much need for additional semver metadata.

from wuffs.