Use explicit Default for GzHeaderState enum

[jongiddy]

While the MSRV policy only requires n-2 support, there's no need to increase it for minimal benefit. Using an explicit Default reduces the MSRV from 1.62 to 1.53.

Is there a rust-lang policy for adding the "rust" MSRV to Cargo.toml?

[Byron]

Thanks a lot. I remember having closed an issue due to that, which is fair, but reverting the change is certainly an option as well.

A problem I see right now is that this can 'break' again, there is no MSRV check on CI right now, and if it was I could imagine setting it to 1.53 sends an unintended message. After all, then the policy would be a different one.

Is there a rust-lang policy for adding the "rust" MSRV to Cargo.toml?

I don't know, maybe posting it on Zulip has a higher chance of getting a more official response.

Even though I approve of this change as more-compatible seems better to me, I would be glad of @joshtriplett could chime in before this is merged.

[jongiddy]

For context, the increase to 1.62 was added unintentionally by me in the most recent release, and #370 is the issue that @Byron mentions.

Adding the MSRV to Cargo.toml should definitely be accompanied by CI validation, with the intention that MSRV bumps are detected and noted in future releases.

[Byron]

Thanks for the context, it's very helpful.

This makes me see the situation as follows: for quite some while the effective MSRV was 1.53 even though it wasn't written down nor validated. This led to a regression at least as seen from the perspective of habit - this crate used to work with 1.53 after all. Habit usually is worth protecting even if it a policy wouldn't consider this a regression.

Thus I think it's worth to add an MSRV check even in this PR to prevent future regressions, probably along with a version entry in the Cargo manifest. This only poses the problem that it then becomes undefined when the MSRV should be changed. What's worth changing it, and what is not? I think it's all about what the mindful humans in the maintenance team and the community think without the need to cement it in policy.

If this was me alone, I'd probably add a line to the MSRV policy that says we don't change the MSRV unless there is a good reason for it - it's a good service provided to the widespread audience of this crate.

As this involves the MSRV policy I'd still hope for more to chime in.

[joshtriplett]

The stated and documented MSRV policy is the last two stable versions of Rust. A crate that goes a long time without raising its declared MSRV can become perceived as having an older MSRV by policy rather than by accident, but that doesn't actually mean it has an older MSRV policy. And worse, a policy of "we don't upgrade until we need a new feature" tends to result in relitigating the MSRV policy for every new feature used, with proposals to rewrite the code to not use the new feature.

Part of the point of the MSRV policy is to not have to avoid using features like these. It is important that CI test the MSRV, so it'd be helpful to modify CI to test the declared MSRV, and we should declare rust-version = "1.71" in Cargo.toml and bump it regularly. But I think an MSRV policy that doesn't actually upgrade until a new feature is "needed" would de facto be a much longer MSRV window than the actual MSRV policy of this crate.

If we want to change the MSRV policy of this crate to be more conservative, we could talk about that, but that would be a change. But also, packages needing an older MSRV could use an older flate2 (by setting it in their lockfile, and ideally not pinning it), and future versions of Cargo will make that easier.

[Byron]

Thanks a lot for chiming in!

I hear that whatever the policy, there should be a rustc-version = X" line, and the MSRV should be tested by CI as well, and also believe this would be an improvement in any case. With it, #370 could have been avoided.

As for the policy, I'd love to start a conversation about possible changes. Not as a maintainer but as a user of the crate I know that updating the rustc-version field without need will cause churn downstream to all who don't have a compatible MSRV policy. As example, I use the time crate which now, probably for good reason, needs a more recent MSRV than what gitoxide supports and I needed to pin it in my own Cargo.lock, while having to remember that I can't do cargo update anymore. The MSRV of gitoxide is currently pinned to the one of a major consumer, helix, which is bound to the MSRV of Firefox. I find this 'MSRV dependency chain' quite revealing as the crate in the middle gets caught in a tug-of-war even though it has no interest in it 😅. If flate2 would adopt a policy that is even closer to the latest version, I would have to pin it similarly (via Cargo.lock) and keep it in mind. Doable, but definitely churn.

With flate2 one wields a lot of power and it could be used to nudge downstream to adopt different policies, but I fear there will be some who are unable to adopt it nonetheless and experience a higher maintenance burden due to it.

[joshtriplett]

I am hoping that the future availability of the MSRV-aware resolver in Cargo will help to address the problems that currently require manually identifying and using a previous version.

[Byron]

Such a resolver would definitely be helpful here. However, I think decisions should be made based on the current technology level and ideally consider all parties, the policy makers and the people downstream of it. It would be a real issue, currently, if a rustc-version field would be introduced that follows the policy and isn't motivated by a technical need due to the additional burden for those who can't adopt it.

In a for me optimal world I could ask Rustc for the minimal required rustc-version value and run with that until there is a technical need to upgrade it. This seems to be fair use as it's driven by need and not policy (but maybe that is the policy then). From explaining a motivation for what would be an 'as-needed' policy I realize that I don't understand the value system behind the 'follow-the-latest' policy. Thanks for bearing with me here 😅.

[jongiddy]

I probably chose the wrong terminology for the title of this PR. In some sense "MSRV" is the equivalent of a Tier 1 target for the compiler. A change that stops the MSRV building and running is not acceptable.

In this sense, version 1.57 is a Tier 3 target. There is no expectation of support and we prefer enhancements for Tier 1 over continued support for Tier 3. At the same time, there's evidence that someone uses it and hence no desire to break it unnecessarily.

Derived defaults for enums is a useful feature, but very much a minor convenience. I'd prefer that people who are using 1.0.26 could benefit from fixes for a while longer, and ideally have Cargo automatically pin them to the last release that works.

[Byron]

I like the idea of keeping separate topics separate and focus on the fix which is the prime intention here. Hopefully the MSRV parts of the conversation can lead to other portions of the project to see improvements as well.