Develop 0.4.4-beta.*

[qryxip]

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-in cargo add command and the cargo-add command from cargo-edit does not resolve -beta versions without explicit specification.

[qryxip]

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

[qryxip]

does not resolve -beta versions without explicit specification

Example: https://docs.rs/salsa

[statiolake]

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.

• To disable all v0.4.x, I need to yank v0.4.3, since it already contains features incompatible with AtCoder.
  (discraimer: I'm not familiar with cargo's behavior. Also I'm not sure how users prepare their project before contest.) I think most users are reusing their Cargo.toml among contests. If it contains previously generated 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.
• (less important) Other usage not restricted by AtCoder's version (such as including this crate to another judge service, using this crate in simple standalone command line tools, using this crate with some bundle tools, and so on) should use rather v0.4.x. To tell those users to use "beta" version (semantically it is a normal v0.4.x) seems a bit unnatural for me. However, since proconio's primary target is AtCoder, it is less important thing.

This is just my thought. What do you think?

[qryxip]

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 to confirm this

❯ # crossbeam v0.5.2 is yanked
❯ rm ~/.cargo/registry/cache/github.heygears.com-1ecc6299db9ec823/crossbeam-channel-0.5.2.crate
❯ cargo init
     Created binary (application) package
❯ cargo add 'crossbeam-channel@=0.5.0'
    Updating 'https://github.com/rust-lang/crates.io-index' index
      Adding crossbeam-channel =0.5.0 to dependencies.
             Features:
             + crossbeam-utils/std
             + std
             - crossbeam-utils
❯ cargo generate-lockfile
    Updating crates.io index
❯ sed 's/"=0\.5\.0"/"0.5.2"/' -i ./Cargo.toml
❯ sed \
>   -e '/^name = "crossbeam-channel"$/{n;s/0\.5\.0/0.5.2/}' \
>   -e 's/"dca26ee1f8d361640700bde38b2c37d8c22b3ce2d360e1fc1c74ea4b0aa7d775"/"e54ea8bc3fb1ee042f5aace6e3c6e025d3874866da222930f70ce62aceba0bfa"/' \
>   -Ei ./Cargo.lock
❯ cargo check
  Downloaded crossbeam-channel v0.5.2
  Downloaded 1 crate (87.8 KB) in 1.40s
   Compiling crossbeam-utils v0.8.8
    Checking cfg-if v1.0.0
    Checking lazy_static v1.4.0
    Checking crossbeam-channel v0.5.2
    Checking pkg v0.1.0 (/tmp/pkg)
    Finished dev [unoptimized + debuginfo] target(s) in 2.58s

How about this?:

1. 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: () = ();
   };

2. Yank 0.4.0, v0.4.1, v0.4.2, and v0.4.3.

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.

[statiolake]

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.

[qryxip]

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.