cc @rust-lang/libs any thoughts on stabilizing getopts?

👍 to documenting this strict backwards compatibility somewhere and to releasing as 1.0.

• This crate is certainly used by many.
• We already can't break anything about the parsing semantics.
• The API didn't have any breaking changes since January 2015 (!!), when 0.2.0 was released.
• Since new, more easy to use (IMO) libraries for CLI args parsing have emerged (clap, structopt), I think the purpose of this library should mainly be stability at this point.

My impression is that the recommended way to parse command-line arguments in Rust is to use clap or structopt (which is based on clap). I feel that releasing 1.0 would encourage more people to use this crate, which is something we don't want.

which is something we don't want.

I agree with that. But I don't think a release necessarily drives people to use this crate. A crate that's used a lot and promises stability but is version 0.x.x seems like it doesn't use semver correctly. Additionally, we can communicate our intentions in the release notes and in the README. And we don't need to publicly announce the release.

What about bumping to 1.0 and moving it to rust-lang-deprecated?

What about bumping to 1.0 and moving it to rust-lang-deprecated?

Hmm, I guess it's less deprecated and more fixed. Unless @rust-lang/compiler were looking at replacing getopts with something like clap? Or if they're happy to depend on libraries in the deprecated org.

I feel that releasing 1.0 would encourage more people to use this crate, which is something we don't want.

We could add some more docs to the readme pointing users to clap/structopt? It's a little bare at the moment.

Is there a reasonable path for rustc to move to clap/structopt? If so, we could remove this dependency entirely in favour of the community crate.

@oli-obk I’m not sure to be honest but that sounds like something worth pursuing!

Since this PR doesn't actually do anything with stabilization I'll go ahead and merge this disclaimer.