Roadmap to 1.0?

bbqsrc commented

2019-12-19 03:28:55 -06:00

(Migrated from github.com)

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?

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 commented

2019-12-19 06:21:18 -06:00

(Migrated from github.com)

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

dekellum commented

2019-12-19 11:13:57 -06:00

(Migrated from github.com)

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 commented

2019-12-19 11:16:30 -06:00

(Migrated from github.com)

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

dekellum commented

2019-12-19 11:34:54 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 11:37:58 -06:00

(Migrated from github.com)

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 commented

2019-12-19 11:59:28 -06:00

(Migrated from github.com)

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.

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: ``` toml 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". ``` toml links = "virtual_rust_crate_log" ``` This makes it so there can only be one log crate version resolved.

sfackler commented

2019-12-19 12:26:29 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 12:32:46 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 12:34:28 -06:00

(Migrated from github.com)

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

sfackler commented

2019-12-19 12:38:19 -06:00

(Migrated from github.com)

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 commented

2019-12-19 12:43:01 -06:00

(Migrated from github.com)

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?

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: ``` toml 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 commented

2019-12-19 12:46:29 -06:00

(Migrated from github.com)

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 commented

2019-12-19 12:55:07 -06:00

(Migrated from github.com)

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.

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: ``` diff -httparse = { version=">=1.2.4, <1.4" } +httparse = { version=">=1.2.4, <1.3" } ``` The dep graph looks like this (with httparse downgraded): ``` txt 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 commented

2019-12-19 13:07:12 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 13:12:48 -06:00

(Migrated from github.com)

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

> 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 commented

2019-12-19 13:13:44 -06:00

(Migrated from github.com)

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

dekellum commented

2019-12-19 13:17:45 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 13:29:00 -06:00

(Migrated from github.com)

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 commented

2019-12-19 13:38:48 -06:00

(Migrated from github.com)

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

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

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 commented

2019-12-19 14:45:48 -06:00

(Migrated from github.com)

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?

> 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 commented

2019-12-19 14:50:46 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 14:57:25 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 15:01:22 -06:00

(Migrated from github.com)

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.

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 commented

2019-12-19 15:17:58 -06:00

(Migrated from github.com)

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.

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.

Rows
Columns

Roadmap to 1.0? #375