Roadmap to 1.0?

[bbqsrc]

As the log crate is a very core part of the Rust ecosystem, it would be wonderful if by the end of 2020 it could join the set of illustrious crates that have begun to follow strong semver by releasing a 1.0 version.

Is it time we make a roadmap to that goal? Are there things blocking that from happening?

[sfackler]

Figuring out key-value arguments is probably the main blocker.

[dekellum]

The sooner the better IMO. The alternative of releasing new features in PATCH versions, e.g 0.4.9 0.4.10 have caused regressions, been yanked, etc.

[sfackler]

Uh, how would a 1.0 release have made those releases not broken?

[dekellum]

Uh, obviously, if you have log = "0.4" in Cargo.toml, then a 1.0.0 release doesn't effect you. I suspect the majority of users aren't yet using the key-value feature.

[sfackler]

The change was explicitly designed to be backwards compatible. There's ~no way it would have been first added in exactly the 1.0.0 release, just like it wouldn't have been added in an 0.5.0 release.

[dekellum]

0.4.8 could have and could still be released as 1.0.0. Then rightly (unless you or the rust community still wants to do things "different") the key-value feature changes could be released as 1.1.0. As in MINOR bump for new features, and any MSRV increase, as well. Yes by default, that is still a SemVer compatible version, but in practical terms it has the advantage of allowing users to constrain as follows if needed:

log = ">= 1.0.0, < 1.1" 

This would be more common in applications than library crates. Then any safe bug fixes can still be backported to 1.0.1, 1.0.2 etc.

Finally, I think the log crate should "appropriate" ("misuse" if you prefer) the Cargo.toml links feature to avoid needing to do this whole SemVer dance and dtolnay-hack of releasing a 0.4.x "compatibility shim".

links = "virtual_rust_crate_log"

This makes it so there can only be one log crate version resolved.

[sfackler]

In practical terms, no one can use that style of dependency constraint due to Cargo's version resolution algorithm. If any other dependency has a more traditional ^1.0 constraint, it will fail to resolve a crate graph.

Adding a links to a 1.0 release wouldn't do anything since none of the other major versions of log have one. If they did have one, it would be profoundly catastrophic to the crate ecosystem as it would require a breaking release of every crate that depends on log either directly or transitively.

[dekellum]

So the status quo working well, in your opinion? How many yanked releases?

no one can use that style of dependency constraint due to Cargo's version resolution algorithm.

I don't believe that is the case. If that were true how does cargo install barc-cli manage to work? (See barc-cli application and body-image library for examples of these kinds of constraints.)
Please educate me?

On the later point, you could release a 0.4.11 (yeah, 0.4.9 would have been nice but oh well) to establish the links metadata.

[sfackler]

Since log was first published to crates.io 5 years ago, there have been 3 yanked releases out of 40 total.

[sfackler]

What set of dependencies in barc-cli and body-image should I be looking at? They all appear to match exactly between barc-cli and body-image, and all of the constraints for 0.x versions are the same as the standard constraint.

[dekellum]

Well, I'm not sure what you are looking for, but there is this tool called cargo tree that can help! (Yes I know you wrote it, thanks!)

One example might be:

https://crates.io/crates/body-image-futio

has:

httparse = ">= 1.2.4, < 1.4"

...but still works fine with hyper 0.12.x. I just haven't observed the problems you speak of?

[sfackler]

The crate will fail to resolve a dependency graph if an httparse version greater than 1.3.x exists and any other crate in the dependency graph has version constraints that would allow the new version. There is no httparse version newer than 1.3.x right now, and I don't know what the rest of your crate graph looks like.

[dekellum]

I'd like to see an example (empirical evidence) of such a failure, before waiting for a new httparse release! Is this some well documented cargo limitation or bug? Why can't it be fixed?

As an experiment, I went and changed body-image-futio in tree to the depedency on httparse:

-httparse   = { version=">=1.2.4, <1.4" }
+httparse   = { version=">=1.2.4, <1.3" }

The dep graph looks like this (with httparse downgraded):

httparse v1.2.5
├── body-image-futio v1.3.0 
├── hyper v0.12.35
│   ├── body-image-futio v1.3.0  (*)
│   └── hyper-tls v0.3.2
│       └── body-image-futio v1.3.0 (*)
└── hyperx v0.15.2
    └── body-image-futio v1.3.0 (*)

and hyper has: httparse = "^1.0" and httparse 1.3.4 exists. This seems to match what you are saying and still manages to resolve without duplicates.

[sfackler]

Oh great, it looks like range dependencies may have been fixed.

In any case, the existence of a 1.x.x version does not prevent people from cutting buggy releases.

You are free to lead a crusade to have the world switch to range dependency constraints, but I don't really see that going very far.

[dekellum]

In any case, the existence of a 1.x.x version does not prevent people from cutting buggy releases

If SemVer is actually followed (a big if, I've come to realize), then new features get MINOR version bumps and those buggy releases only effect users that choose less-conservate dependency ranges (like the current default "1.0" or "^1.0" style.)