Command-line-api: Release schedule

[dashesy]

Is there a milestone on when this package will be out of alpha?

[jonsequitur]

There are a few decisions to make. We definitely want opinions on these. Here are a couple that are on my mind regarding System.CommandLine.Experimental:

• The package name is going to change (#504). What should it change to? Is the current layering correct? For example, portions of System.CommandLine (model binding, middleware) are more geared toward building applications, so the System namespace might not be appropriate for all of it. Other parts (IConsole, ITerminal, ANSI support) feel more foundational but not fully worked through (e.g. #275), and they're not reconciled with System.Console.

• Is the API stable enough and simple enough? Option<T> is new and needs work. A lot of people run into naming convention gotchas with model binding. We would love to know what other parts of the API feel unfinished.

• Suggestions and directives (e.g. [parse]) are protocols as much as implementations. Other platforms could use these conventions. Do they need a wider discussion?

[KathleenDollard]

@dashesy I hate to ask a simple question here, but...

What is the meaning/importance of alpha to you? What do we need to be "out of" and what would that look like? (like quality? API not changing?) I think this will make it easier to answer your question.

Also, what parts of System.CommandLine are important to you.

[dashesy]

Of course! the quality of System.CommandLine as-is is better than many non-alpha packages. I already am using this in some new internal utilities to replace Microsoft.Extensions.CommandLineUtils . The fact that it is pre-release, and does not show up in NugetManager (without checking include prerelease) is a red flag that I am sure throws off many users. If the utilities were user-facing using alpha package may not pass a PR review.

We currently use very simple System.CommandLine and few sub-commands. They are stable enough, maybe you can release them at first and keep the rest of the API undocumented (and thus subject to change).

I actually quite like the current interface. Option<T> along with TryConvertArgument suffice for all of our needs. Verbosity is no issue, I just think there should be more examples.

[jonsequitur]

On the road to a proper release, we've removed "Experimental" from the package name. Here are the next steps:

• We're working on some breaking changes that we've held off on. These are focused on simplification: cleaning up some redundancies, moving some types into more specific namespaces (#717), and making Option<T> more complete so that you won't always need to access its Argument property for things like suggestions, default values, and custom validation.
• We'll start adding XML documentation to the code.
• Later this month, we'll be doing an API review, with user studies to follow shortly.
• The version will change to a 2.0-beta version number, making it a successor in terms of SemVer to the older System.CommandLine. It's not clear that the other packages are ready to come out of alpha yet.

[paclavie]

When will alpha be removed from System.CommandLine.DragonFruit? I am coming up on my release in less than a month and I will get blocked by the designation of this component is still in Alpha. But glad it is no longer in experimental that may help with my upcoming code review.

[345paul]

Any more news on when this might be released? Also the same for the Hosting package.

[adamralph]

It would probably be good to take some of the content from some of the comments here, e.g. https://github.com/dotnet/command-line-api/issues/700#issuecomment-561485243 and https://github.com/dotnet/command-line-api/issues/700#issuecomment-570948319, and put them into a wiki page which shows the current status, and can updated as it changes.

[majastrz]

Is there a plan to move out of pre-release versions yet? Or will this stay in beta for the foreseeable future?

[jonsequitur]

Please refer to the milestone.