feature/legacy support

[rustysec]

updated solution #91, simple feature toggle without any code modifications. i added a couple of test cases that show the error handling still works even with --no-default-features --feature=legacy-support enabled (all test cases are passing).

[rustysec]

the travis failure gets cleaned up if you do a cargo clean between builds. let me see what i can do to make travis behave.

[punkstarman]

@rustysec, the caching problem was encountered on the master branch. I fixed it by manually clearing the cache on that branch. I believe that the problem happens when a new version of Rust is released.

I'd rather not remove caching entirely because it does speed up the CI considerably. I'd rather open a new issue to investigate this problem.

[rustysec]

Gotcha, I will fix the config

[rustysec]

stable is failing in travis, but beta and nightly are working. i'm building with stable on my machine(s) and all is well.

[punkstarman]

I wonder if the build failure is due to an issue on docmatic (assert-rs/docmatic#4)

[RReverser]

@punkstarman That does sound realistic. I wonder if we could just drop Nightly from the testing matrix - in my experience, it should be always backwards-compatible with stable Rust, and when it's not, it's an issue with Rust itself and not with the crate so testing is sort of pointless.

[punkstarman]

@RReverser the problem is on Stable not Nightly.

I don't mind removing Nightly from CI script. Yet, IMO the point of building with Nightly is to possibly anticipate rare occasions where backwards-compatibility will break and to help detect regressions in Nightly. Also, the current CI script ignores failed Nightly builds.

  allow_failures:
    - rust: nightly

[RReverser]

I see, I got confused by reading the linked docmatic issue. As far as I understand comments there, cleaning the cache for package itself works around this problem?

If so, maybe worth trying to cargo clean -p serde-xml-rs as part of Travis script (probably even as part of before_cache step)? This should still speed up most builds significantly, and is a more gentle / reliable option than the suggested rm -rf ....

[rustysec]

I think that would work, Travis worked when I flipped caching off in the yaml. This solution would be better.

[punkstarman]

I'm game for trying cargo clean ... as a before_cache action.

[rustysec]

the key seems to be removing the old cached lib from the build directory.

[rustysec]

i thought cargo would do that, but a simple rm handles the problem instead

[RReverser]

That's weird, I'd indeed expect Cargo to handle that.

[RReverser]

Btw, I see you moved commands from before_cache - any specific reason?

[rustysec]

it didn't work in either place, only when i added the rm did it build

[RReverser]

Yeah, but I suppose the difference was in rm so now cleanup can be moved back to before_cache?

[RReverser]

(I mean rm itself as well)

[rustysec]

aha sorry about that

[rustysec]

is there anything outstanding on this?

[RReverser]

I think it would be good to clean up commit history (to avoid lots of small cleanup commits, and also avoid them showing from two different authors) but otherwise LGTM, leaving to @punkstarman for final review.

[rustysec]

i think a squash merge is a good idea

[punkstarman]

LGTM too.

Concerning clean up or no, I don't mind either way. I'll do a squash merge.

@rustysec, I'll also tag and release to crates.io soon.

@RReverser, for my personal continuous improvement, I'd be interested in understanding why cleanup is important to you.

[RReverser]

@punkstarman I believe clean, maintained commit history can serve a list of useful purposes while not being too hard to keep:

1. When each commit is an atomic self-descriptive change, it's easy to treat the log itself as a CHANGELOG for those interested, rather than having to maintain one separately.
2. When each commit individually is in a working condition, then, when a bug is found, you can do git bisect run ... to automatically find where it was introduced, and not stumbling on intermediate failing WIP commits.
3. git blame as well as commit view become more clear to read and it's easier to see which changes were introduced together, which is often useful to understand why particular API or test exists.

There might be more, but these are the ones I can name off the top of my head.