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.)

[sfackler]

Which is ~everyone except you (that's the crusade part).

[dekellum]

The advantage of releasing 1.0.0 sooner is not predicated on anyone using those "exotic" range constraints! Your painting me as a "crusader" as a straw man argument to maintain the status quo.

[sfackler]

What difference would people using normal version constraints see? Those releases would have been buggy, have caused breakage, and been yanked whether they were numbered 0.4.x or 1.1.x.

[dekellum]

A related Question: Why does SemVer require that new features get MINOR version bumps.

Answer: Because new features always entail some risk of regression.

[dekellum]

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.

This smells like FUD, but I'll play along: Wouldn't any SemVer non-compatible new release, which given the present 0.x state, includes 0.5.0 or 1.0.0 cause the same "profound catastrophe"? I mean, since the entire ecosystem needs to, you know, upgrade?

[sfackler]

No. If we just cut an 0.5 with no extra compatibility work, you would continue to compile, but maybe lose logs from some dependencies until they update. In reality, like we did with 0.3, we would do extra compatibility work and make old log versions forward up to the new one.

If you did the links thing, you need to have your entire transitive crate graph agree on the new version before you can upgrade anything that depended on log.

You haven't answered my question, by the way.

[dekellum]

And to be clear "compatibility work" means: The dtolnoy-semver-hack of releasing a "compatibility shim" that brings in the new version under a PATCH release to the old version. I say "hack" because this violates the most basic concept of SemVer, effectively forcing a non-compatible update in a PATCH release.

So yeah, I'm fairly convinced that links is a better way to handle this.

[sfackler]

I am not aware of any incompatibility to existing log 0.3 users when we added the shim.

You are welcome to manage your libraries in a way that will have 10,000 people screaming at you whenever you cut a new breaking release, but that's not how I look to manage libraries. I am far more interested in building things that work than I am worried about the Semver SWAT team kicking my door in and hauling me away for breaking the rules.

[dtolnay]

I am going to lock this issue because I don't expect that continuing this discussion in the current direction and the current tone will turn out to be productive. Clearly there were things wrong with the recent 0.4 releases that were quickly yanked, and @dekellum has some ideas that solve some particular problems, but so far it doesn't sound to me like those problems are the same problems that log actually has.

To answer OP's questions: I am sure the maintainers have 1.0 in mind but they want to resolve the design of structured logging (#149, #328, #343) before that point.