Package version is 1.x, even though API is *not* stable

[crumblingstatue]

In #60, the version was bumped to 1.0.0. This was a mistake, as our API is still unstable. At the very least, we depend on an unstable sdl2 crate, so every time we update our sdl2 dependency, it's a breaking change.

This means that we would have to increment the major version (i.e. 2.0.0, 3.0.0, ...) after every sdl2 upgrade.

I'm not sure if this can be fixed (either by yanking, or by special request, deleting for good our 1.x versions from crates.io), or if we are stuck having to upgrade the major version every time we make a breaking change.

[andelf]

crates.io supports yank. cargo yank
sdl2_mixer, sdl2_ttf use same version string as sdl2.
@xsleonard

[xsleonard]

@andelf are you able to admin the package on crates.io?

[andelf]

@xsleonard yes.
yanking 1.x will break following repos. :(
serarch result

Better to inform them before we do this yanking.

[andelf]

I'll yank v1.1.0 and v1.0.0.

[crumblingstatue]

@andelf Is it actually possible to start releasing lower versions than the ones we already published, even if we yank them? I'm concerned.

[andelf]

@crumblingstatue

The semantics of a yanked version are that no new dependencies can be created against that version, but all existing dependencies continue to work.

[andelf]

I've published v0.16.0.

but our crates.io homepage shows:

This crate has been yanked, but it is still available for download for other crates that may be depending on it.

It only displays newest version of the create by default. :(

should we make a feature request to creates.io?

[andelf]

refer: rust-lang/crates.io#76

[andelf]

😂 Should we publish a new v1.1.1? Currently our crates.io page is completely gone.

[crumblingstatue]

Should we publish a new v1.1.1?

That would only make the situation even more confusing. We caused enough mess as it is already.

[crumblingstatue]

Closing, since this crate is deprecated.