[Mono-list] C# command line parsing library

[Miguel de Icaza]

Hello,

> I don't think it has too much limitations, but I would like some bug
> reports for any limitations or lacking features that all of you, users
> and potential users of it, could file to assess what I should improve.
> Direct code/documentation contributions are also welcome.

As I explained to a volunteer that contacted me over email, the problem
is not only related to the existing limitations of Mono.GetOptions, but
it is further constrained by the fact that further API changes are not
likely going to go in (because it would break older applications).

API additions, updates and changes are better suited to an upgraded API,
and if I were to make the decision today about shipping a GetOptions
library, I would not put that in the core of Mono.

This goes to a more general issue: I think we were too lax accepting new
APIs that were evolving into the Mono core, which is why these days the
answer to "Could you bundle MyFavoriteLibraryThatIJustDeveloped in Mono"
is "no".

Because we have to maintain backwards compatibility, this means: if you
break the API, we have to ship *two* versions of the library (see
ICSharpCode.ZipLib, we ship *two* because of this) and we have to carry
the burden for these API changes.

We have documented the process to have unstable APIs in the "Application
Deployment Guidelines" on the Wiki, and many of the APIs that today we
ship with Mono should have gone first through that process, and only
when stabilized bundled with Mono.   

Bundling stuff with Mono imposes a lot of constraints on developers: API
stability, tests, release schedule.   But it also imposes a lot of extra
work on us: if a critical bug, security problem or something else is
found on those libraries, we must stop whatever it is that we are doing
and start the release process, the advisory process and get things
moving to address the issues.    

This is why we moved Olive into its own release schedule: because the
core of Mono is stable, has calcified and Olive is better served with a
process that has its own release schedule, that can release updates as
frequently as it needs (when its ready to ship) and can fix bugs on its
own schedule.

And this is also why we are doing it for Basic, mbas is dead, its gone
from the tree, and so are the class libraries for Visual Basic: the vbnc
and vbruntime components are younger, and need to be on their own
release schedule, they are moving at a different speed, and bundling
with Mono just imposes a structure that is not apt for technologies
under heavy development. 

We would have done the *same* for Windows.Forms, were it not for the
internal dependencies in our own assemblies (ie, have Windows.Forms
releases that are completely independent of Mono).   

We should have known better;   There is the rule from Brad Cox: an API
is not mature until you have three very different applications consuming
it and not until you have tests cases, understanding of limitations and
expanded features that you should declare it as stable.

Miguel