Can I package beta software that's pretty stable already?

[mfts]

asked via Discord by @johnallen3d

I'm wondering if there's a stance on packaging beta software.
There are a couple of popular projects (dagger.io, surrealdb.com) that don't yet have official release but appear to be pretty stable.
Is it frowned upon to package a beta? If not, would I hard code the most recent beta as the version?

Example of https://github.com/surrealdb/surrealdb

[jhheider]

The main issue would be coming up with a version number. If we used v1.0.0.8 (by stripping -beta out), then v1.0.0 would be a lower version number. It would be nice if their betas were 0.9.8, etc., but we can't ask people to change their processes on our behalf.

So, my thought would be, if the beta is the canonical version, I have no problem with publishing it (see https://github.com/teaxyz/pantry.extra/blob/main/projects/github.com/jart/blink/package.yml for one method of hard-coding a version to a commit sha for a project that doesn't even have a tag yet). But we do have to be careful about version numbers.

[johnallen3d]

Thanks for the clarification @jhheider. It turns out I was wrong about Dagger (there is a release).

As for Surreal, I think I'll PR a wip and wait for an official release.

[mxcl]

So yeah this is fine. As long as things build we are good with them.

However we should preserve the beta tags IMO, which will require changes to tea/cli code. Prepare the package and I'll look at the code.

[jhheider]

1.0.0-beta.8 < 1.0.0, right?
but
0.9.9-beta.7 > 0.9.9?

I think there might be consistency issues to deal with the way people decorate version numbers.

[mxcl]

0.9.9-beta.7 > 0.9.9?

no the beta is before 0.9.9

[mxcl]

We don’t want to generally publish all betas, only packages with some sort of “allow pre-releases” and probs they should specify a version range where it's allowed or something.

[magnusviri]

One solution to the version order is to support a file that explicitly lists the version order kind of like how your spec does it. I'm not giving this much thought, it was just an idea. Here's an example.

versions.yml (or .versions.yml?)

versions:
  - 1.0.0
  - 1.0.0-beta.8
  - 0.9.9-beta.7
  - 0.9.9

Edit to clarify: this file would go in the project, not the package. Obviously, the project would have to add it, but this allows them to keep their version schema.

[jhheider]

Yes, coercing the manifold similar versioning schemes into something that meets the semver standard is an ongoing consideration of ours. One option we'd toyed with was allowing packages to have a custom version.ts script that allowed for programatic handling of whatever they wanted to use for versions. At some point, we'll definitely need to consider maximum genericization of that handling to deal with everything there is.