Yank 0.1.1 and publish 0.2.0

[nox]

The bump to 0.1.1 and its explanation is quite infuriating and totally not like semver. Why was it done this way? Do we have a shortage of version numbers? Are they IPv4 addresses now? Why not just do 0.2.0?

[lukesutton]

Well, like the Semver FAQ says "Major version zero is all about rapid development". I think it's reasonable to say that for anything pre-1.0.0, all bets are off. I understand that versioning can be a touchy subject, but I don't feel this is one to get annoyed about.

[nox]

Except that cargo disagrees on that (0.1.1 should be compatible with 0.1) and people actually got bit by it.

[tomaka]

As far as I know futures would be the first ever Rust crate to voluntarily break the assumption that 0.1.1 is compatible with 0.1.0.

[matt2xu]

Also, I would completely agree with your issue @nox if the library had major breaking changes at a version close to 1.0, or was a mature crate. However, this crate is about 6 months old and only just made its first release at version 0.1, so really at this point you can expect breaking changes (small or not) at almost every release, at least I would 😄

[nox]

@matt2xu That is completely irrelevant. It doesn't matter the age of the crate or whether it is moving a lot or not. Either we follow semver, or I have to explain to people that sometimes their projects will fail to build because even the people in the core team don't care about versioning in such a way that doesn't break downstream. The documentation says that 0.y.z should be compatible with 0.y.z+1, so why break that?

[SimonSapin]

Even if you do so very frequently, it's not hard to increment 0.x.0 instead of 0.1.x for breaking changes.

[matt2xu]

From the documentation, http://doc.crates.io/specifying-dependencies.html#caret-requirements

While SemVer says that there is no compatibility before 1.0.0, many programmers treat a 0.x.y release in the same way as a 1.x.y release: that is, y is incremented for bugfixes, and x is incremented for new features. As such, Cargo considers a 0.x.y and 0.x.z version, where z > y, to be compatible.

"many", not "all" programmers. As @alexcrichton mentioned on the commit message, release 0.1 was just about reserving the name on crates.io, implying that no one should have used version 0.1 anyway. Yes the best may have been to use 0.2 instead of 0.1.1, and indeed there is no upper limit on x in a 0.x version number. Personally I don't see it as a big deal, especially since nothing forces me to use a new, under-heavy-development crate right away. I think it would be good to hear Alex's opinion on this issue.

[tomaka]

"many", not "all" programmers.

Please emphasize "As such, Cargo considers a 0.x.y and 0.x.z version, where z > y, to be compatible.".

The first part says that in strict semver 0.1.1 is not compatible with 0.1.0. Then it says that in practice developers consider that they are compatible. And the last sentence says that Cargo acknowledges this compromise.

implying that no one should have used version 0.1 anyway.
Personally I don't see it as a big deal, especially since nothing forces me to use a new, under-heavy-development crate right away.

I saw that tokio was depending on futures 0.1.0. I then published new versions of my audio crates which depend on futures 0.1.0. Then tokio presumably got upgraded to a new version of futures, while I didn't get the memo.

Now that version 0.1.0 has been yanked, cpal and rodio are unusable.

[jansol]

The documentation mentioned by @matt2xu also specifically mentions the pre-pre-release case:

0.0.x is not considered compatible with any other version.

Which IMHO would have been appropriate here.

Anyway, yanking the previous version when pushing a new one is doing nobody a favor and will just piss off people at this stage. After 1.0.0 I can somewhat agree to yanking at least old minor versions, but right now it just seems to be about purposely breaking everything.

[nox]

release 0.1 was just about reserving the name on crates.io

Name squatting crates are usually empty to not be depended upon. You just don't name-squat with a crate that actually contains code and becomes depended upon by the rising tokio crate.

[jansol]

Name squatting crates are usually empty to not be depended upon. You just don't name-squat with a crate that actually contains code and becomes depended upon by the rising tokio crate.

And AFAIK usually marked as version 0.0.0

[nabijaczleweli]

Or 0.0.1, but yeah

[lilianmoraru]

I've just hit the problem where poll from Future trait has changed the parameters and I was not understanding why it doesn't work(I was also reading 0.1 docs from docs.rs), seems like this was the reason.
Easy to fix, but strange, it goes even against cargo's assumptions...

[alexcrichton]

Thanks for the report, but unfortunately now I think we're in a situation where the damage is done. More harm will happen if 0.1.1 is yanked and 0.1.0 is "republished". In that case I'm going to close this, and if 0.1.0 is really needed it's available in git.

[nox]

Could you confirm that bumping to 0.1.1 was an error?

[nabijaczleweli]

the damage is done

He has