crates.io version is out of date

[reem]

the fixes on master haven't been pushed

[SimonSapin]

I can publish a new version to fix the issue for now, but it’s going to be out of date again the next time master changes. Especially pre-Rust 1.0, there’s gonna be churn for language upgrades. So I’d rather figure out a more general way to work with crates.io. How do you deal with this in other projects? I can imagine a couple ways:

• Let crates.io fall out of date, ignore it until Rust 1.0, and use git dependencies in the meantime.
• Publish a new version whenever a maintainer feels like it, or someone asks for it.
• Time-based releases: Every X amount time (a week? 6 weeks? every day?), publish whatever is in master as a new version.
• Whenever someone pushes to master or merges a pull request to master, they are responsible to publish that change as a new release
• Set up Travis-CI or whatever automation to publish a new release whenever master changes

When publishing a new version, one also has to decide which component of the version number to increment. This can be tricky if publication is to be automated.

Also, given that Cargo natively supports git dependency, let’s seriously consider: what is the point of even having versioned publications? It could be to take advantage of semver and get stability, but we don’t get that anyway until the language itself and the standard library are stable.

[SimonSapin]

To clarify: I’m not saying I won’t do it. I’m asking for your and everyone’s feedback on what is a good way to deal with it over time.

[reem]

I think it seems reasonable to just update every time you merge into master for now by bumping the version, though tedious, that would be the best thing going forward (until 1.0 at least).

[SimonSapin]

To be blunt: what is the benefit over using git dependencies? Isn’t this just a lot of overhead to get the same thing in the end?

[reem]

@SimonSapin Honestly I'm just psyched to start using crates.io and I'd like to use it for some new projects that aren't depended on by a lot of stuff.

[SimonSapin]

@alexcrichton @wycats Do you have an opinion on this?

[steveklabnik]

I'm basically planning on just pushing out a 0.9.x release every few days. It's just plain awkward until 1.0.

[alexcrichton]

Yes in general crates.io is going to be rocky heading up to 1.0 due to breaking changes in Rust, but I would personally do what @steveklabnik said with bumping the minor version whenever a breaking change was updated to

[aatxe]

I'm in the same boat here. The crates version not being updated is preventing me from pushing my own work onto crates.io.

[SimonSapin]

I’ve just published 0.2.0 which includes some breaking changes from #52. Feel free to open a new issue or ping this one if it falls out of date again.