Closed qryxip closed 1 year ago
And/Or setting lib.name
to "proconio_beta"
prevent such a situation, too.
[lib]
name = "proconio_beta"
This renaming is also useful for using both 0.3 and 0.4 on AtCoder with a bundling tool such as cargo-equip.
use proconio::input; // enough for this problem
//use proconio_beta::input;
//use proconio::input;
use proconio_beta::input; // I want to use a new feature for this problem
does not resolve -beta versions without explicit specification
Example: https://docs.rs/salsa
Thank you for a good opinion! First of all, I also think we should make it hard to use v0.4 to AtCoder users.
I'm concerning, however, that using prerelease versioning (including renaming to *_beta
) maybe a cause of confusion.
proconio = "0.4.3"
, I think it causes an error (without previously generated Cargo.lock). This is not a big issue if using some helper tools is most popular way and the tools handle this properly.This is just my thought. What do you think?
If it contains previously generated
proconio = "0.4.3"
, I think it causes an error (without previously generated Cargo.lock).
That's true. Yanked crates cannnot be resolved without Cargo.lock, though they are still even downloadable if Cargo.lock remains(※). Just yanking previous v0.4.* would defeat the purpose.
How about this?:
Release v0.4.4 with the following item in proconio/src/lib.rs.
#[allow(path_statements, clippy::no_effect)]
const _: () = {
THIS_VERSION_OF_PROCONIO_IS_DEPRECATED;
#[deprecated(note = "Using proconio v0.4.4 is deprecated. \
This version exists only for avoiding the \
\"failed to select a version for the requirement\" error during a contest. \
From next time, please use v0.3 or v0.4.5-beta.* instead")]
const THIS_VERSION_OF_PROCONIO_IS_DEPRECATED: () = ();
};
Yank 0.4.0, v0.4.1, v0.4.2, and v0.4.3.
Start developing v0.4.5-beta.1.
To tell those users to use "beta" version (semantically it is a normal v0.4.x) seems a bit unnatural for me.
I've forgotten CafeCoder. This competitive programming service currently returns HTTP 500, but if I remember correctly, it is providing proconio v0.4.
Thanks for detailed explanation. Deprecating v0.4 still doesnt seem a good way to me, considering that v0.4 is in fact better version for new users and there's actually another service (CafeCoder) using this, but adding warning is a good idea!
So how about this: adding atcoder_warning
feature to this, and make it default feature. Emit a warning if the feature is enabled. ("deprecated" is a bit misleading message but there's no compile_warning!
macro in std...) When users use this crate in another place, tell them to disable the feature or just ignore the warning. When AtCoder updates proconio to v0.4.x, publish new version v0.4.y removing this warning and start v0.5 (if needed) in the same way.
adding
atcoder_warning
feature
Yes, switching the warning is the most reasonable way to me, but how about adding non-default not-for-atcoder202004
feature instead and making it default when next judge system update is completed?
proconio may be used as a dev-dependency for library crates that are bundled by cargo-equip, cargo-executable-payload, or cargo-atcoder. Suppressing the warning in such case might be difficult because features are easy to enable but hard to disable.
Maybe we should release new versions of crates as
0.4.4-beta.*
.Currently, some people do not seem to use 0.3 but 0.4 for AtCoder. Adding new features such as #26 and #27 may lead to "what the hell my program compiles with Rust 1.42 on the local machine but the submission is CE".
Making the versions
beta
will prevent such a situation because both the (currently unstable) built-incargo add
command and thecargo-add
command from cargo-edit does not resolve-beta
versions without explicit specification.