Please consider a new release with updated dependencies

[kinnison]

I use yaml-rust2 in a project where we're not ready to commit to something as potentially breaking as saphyr. We'd like to eventually since we primarily just use the content which would be in saphyr-parser but for now we're kinda sticking to more stable crates.

Unfortunately we're very size-sensitive and complexity-of-dependency-tree sensitive and as a result we could do with a version of yaml-rust2 which has its hashlink dependency updated to 0.9.

I am prepared to organise a branch and testing to ensure the update is good; though given hashlink's API is part of yours, it probably implies that we would need to do a 0.9.0 release of yaml-rust2 rather than 0.8.2.

Is this something that this project would entertain, given that saphyr-parser does not appear to be presenting as production-ready yet?

[Ethiraric]

I can use the following set of dependencies without changing any piece of code:

[dependencies]
arraydeque = "0.5"
encoding_rs = { version = "^0.8", optional = true }
hashlink = "0.9"

[dev-dependencies]
libtest-mimic = "0.4"
quickcheck = "1.0"

I took the opportunity to remove the patch version requirement, which may help with binary size.
Only the transitive dependency hashbrown would not be updated. The rest would be dev-dependencies.

libtest-mimic has had a bunch of updates, but updating it fires a ton of errors that I don't want to spend time fixing.
I think it probably is a bit too early for a 0.9.0? But I have no experience in evaluating that. I'm not fond of the idea of bumping the minor for just a dependency update.

Since I have not changed any code in the crate, I wonder if it's okay to just release a patch version?
It might break if someone is using a set hashlink dependency on their project alongside yaml-rust2 though.
Something like:

hashlink = "0.8"
yaml-rust2 = "0.8.newversion"

let map = hashlink /*v0.8*/ ::new(something);
let yaml = yaml_rust2::Yaml::Hash(map /*expects 0.9*/);

I'm open to advice and suggestions (cc @davvid)

[GuillaumeGomez]

You can't prevents dependencies to mess up with semver unless you pin each version you're depending on with =.

[Ethiraric]

I am not worried about yaml-rust2 having issues with one of its dependencies. It's more about not messing up consumers of yaml-rust2.

I have no idea how common practice it is to use a dependence and one of its dependence (in this instance someone using yaml-rust2 and hashlink) directly. I have had to do it recently and the experience was atrocious.

I wouldn't want to be "that guy" that messes up other's projects with a patch bump that should have been a minor bump.

[GuillaumeGomez]

There is cargo-semver-check which allows you to check semver breakages.

[Ethiraric]

@kinnison Are you planning to use yaml-rust2 to build marked-data?

There's an issue with saphyr where Marks are off. They sometimes do not return the correct line and/or column and/or index.
Since saphyr's code is based on yaml-rust2, I fear this may suffer the same issue.

Unfortunately, Marks were untested in yaml-rust and I have not written any test for them during development.

[kinnison]

@kinnison Are you planning to use yaml-rust2 to build marked-data?

There's an issue with saphyr where Marks are off. They sometimes do not return the correct line and/or column and/or index.
Since saphyr's code is based on yaml-rust2, I fear this may suffer the same issue.

Unfortunately, Marks were untested in yaml-rust and I have not written any test for them during development.

Well that's worrying. Yes the dependency comes via marked-yaml though the size-sensitively project is within my employer. I've not noticed marks being particularly off except sometimes at the outsides of containers, but for the most part we care about the start location of scalars only.

I have some basic tests in marked yaml for marks but perhaps I should add some more.

[Ethiraric]

If you're able to contribute those to this crate directly, that would be great!

If you use the Parser API directly, you could write test similar to what we have in saphyr. Except the assert_eq! would contain the marks as well.

[Ethiraric]

Also, semver-checks doesn't seem to be concerned about the hashlink dependency:

$> cargo semver-checks
 Parsing yaml-rust2 v0.8.2 (current)
  Parsed [   1.170s] (current)
 Parsing yaml-rust2 v0.8.1 (baseline)
  Parsed [   2.054s] (baseline)
Checking yaml-rust2 v0.8.1 -> v0.8.2 (minor change)
 Checked [   0.007s] 69 checks; 69 passed, 6 unnecessary
Finished [   3.241s] yaml-rust2

[kinnison]

FYI when I updated hashlink in marked-yaml I chose to do a "major" bump because it was a major bump in hashlink and the type is exposed in the API quite strongly. I'd almost suggest making the new version 0.9 in order to follow hashlink's version - it's fortuitous that it's aligned right now and that'd keep things simple for consumers of the library.

[kinnison]

If you're able to contribute those to this crate directly, that would be great!

If you use the Parser API directly, you could write test similar to what we have in saphyr. Except the assert_eq! would contain the marks as well.

The tests inside marked-yaml probably will need faffing with quite hard to make them suitable for either this crate or for saphyr-parser though I'm happy to consider that part of my goal when I sit down to do this. I am very grateful for your (and others') efforts in these libraries and so I'll certainly do my best to gather the energy/effort to help if I can.

[davvid]

I'm not opposed to bumping minors since we're still in 0.x and there's not really any practical downside to bumping up. IIRC semver technically allows breaking changes in patch releases for 0.x versions, but that would be naughty.

[Ethiraric]

Since for now you're the only one needing the hashlink update and you need markers, I think we can release once we have markers fixed? If that sounds reasonable to everyone.

[kinnison]

Since for now you're the only one needing the hashlink update and you need markers, I think we can release once we have markers fixed? If that sounds reasonable to everyone.

I think that sounds fair. I'm unlikely to be able to get to it very very soon, but I'll note it at work as being part of what we need to do to minimise duplicated dependencies.

Thank you for being open to this.

[Ethiraric]

No worries! I want this project to be useful. Wouldn't be if I turned down opportunities to improve ;)

I'm nearing the end of a heavy saphyr-parser refactor to better optimize in-memory string handling.
If all goes well and I didn't kill performance too much on other benchmarks, I might merge that and get to fixing markers.

[Ethiraric]

Actually, I could specify the dependency as hashlink = "0.8, 0.9". What is exposed of the API does not seem to change much since no test break. This would enable users to use either version as they please, and use 0.8 or 0.9 as they need.