changelog.md about body-parser

[e-oz]

You are right about semver rules. It's just young age of Rust ecosystem in general - using it is a living on the edge :)

[e-oz]

Thanks for reply. Not sure how it's supposed to use in production, if Serde is not in beta and will not be there in foreseen future.

[untitaker]

Serde can be used in stable Rust with a build script, but you can also use it without codegen and therefore without build script. No idea what you mean with "not in beta".

I don't see sense in adding a changelog before 1.0.

[e-oz]

Serde can't be even compiled in beta/stable.
By "not in beta" I mean not in non-nightly branch.
By semver rules breaking changes should increment major number of version, so I asked at least document breaking changes, if changing version is not desirable by some reasons.

[untitaker]

Serde can't be even compiled in beta/stable.

It does compile on my machine and Travis.

By semver rules breaking changes should increment major number of version

I agree. Where did you see this violated?

[untitaker]

Also, please spare your passive-aggressive tone and rather consider that I'm doing this in my freetime. I'm not customer service.

[e-oz]

Try to add some usage code and it will not compile.
Breaking change is pretty simple: I use bodyparser 0.0.6 and rustc-serialize and my structures are annotated for it. Upgrade to latest bodyparser breaks compilation.

[e-oz]

It's not agressive tone, it's just annoyed by "work on my machine"-style responses. Thank you very much for your work, hope this issue will be useful for somebody else also.

[untitaker]

Try to add some usage code and it will not compile.

The examples are tested for each commit in Travis. Those are usage code. What are you talking about?

It's not just "works on my machine", it's "it works on Travis, my machine and apparently for everybody else". Therefore I'm also a bit annoyed when you imply that this crate is broken in some obvious way.

Breaking change is pretty simple:

I think you misunderstand how semver works. Before 1.0, every 0.x release is allowed to contain breaking changes. See http://semver.org/#spec-item-4, but it's common practice to not do any breakage on PATCH releases (only on MINOR).

You need to set version to "x.y" in your Cargo.toml to avoid accidental upgrading to a non-compatible version.

[untitaker]

Sorry, actually there's only nightly tests in Travis. I've now added stable, but those are IMO unlikely to fail. Serde itself does have such tests.

[e-oz]

If traits of Serde (serialize/desirialize) are not derived by structs, it obviously will not compile. That's what I've tried to describe.
I think we both loosing time in this arguing, let's just close and my experience will be only my experience.
Sorry for inconveniences.

[untitaker]

If traits of Serde (serialize/desirialize) are not derived by structs, it obviously will not compile. That's what I've tried to describe.

Okay, but that's just the "breaking change" part... as said, it's covered by the version scheme though.

I'm rather open-minded about a changelog, but it's extra work. I don't know if anybody wants to do this work if Iron in general is already a bit undermaintained.

[Hoverbear]

I'd note that according to semver as long as the version major is 0.x.x any change is allowed to be breaking.