announcement: working on next beta started

[gsscoder]

The next Beta will break some public API compatibility (nothing drastic!), for this reason the version will jump to 1.9.4.9* increasing until will reach first 1.9.5.0 Stable.

But you are not interested in my version naming policies, right?

All new and "unfixed" issues will be taken into account for this new release.

So please don't expect pull-requests made on 1.9.3.* to be merged: I can't keep more branches active on this project. Anyway don't stop posting! Good ideas will be incorporated if possible in 1.9.4.9* Beta. Please be patient if some good pull request were not merged, but consider also that sometime is more simple to me fix something by description that solve source code conflicts.

Anyway thanks everyone, for interest in this library. Your collaboration made it better!

Regards, Giacomo Stelluti Scala

[nemec]

If you're looking for ideas for new features, check out Python's argparse module. It's one of the best commandline libraries I've ever used. Obviously it takes advantage of Python's dynamic typing in a lot of places, but perhaps features like actions, choices, or nargs may be nice candidates for inclusion in the next beta.

[alexanderfast]

How about creating a milestone for the next beta? That way we could get some insight into whats included and whats not.

Any plans on when the first 1.9.4 version will be pushed so we can create new or rebase pull requests?

[gsscoder]

Thank Nemec for suggestions about argparse (it's a very well done piece of python code, no doubt!). And about Python let me say that I love it and I'm planning to commit some template in IronPython (if someone likes to write it, is wellcome... other Iron* DLR langs are welcome). Alexander, you're right in fact I didn't commit nothing until 1.9.4.91. And now we are finally here!!!

Please also be patient if not every thread is read or if some suggestion or idea or even interesting pull request lost.

I try to do of my best between open sourcing and ordinary job and to be honest before now my knowledge of git was sufficient (at job we use SVN). Now that the project is really growing and the number of active contributors too, I'm aware that out there's a lot smarter way to manage sources. Anyway time is also a constraint and I prefer put more effort in engineering solution that in coordinating things (which I know that could and probably is a criticizable point).

+++Source layout is now quite stable to receive again new pull requests and for further progress I've various things in mind.+++<<<

1) I'd like to follow Nemec suggestion about the use of double dash (--, https://github.com/gsscoder/commandline/issues/31#issuecomment-11767687) for force all tokens to [ValueList].

2) I want to provide better integration for localization (we already have the SenteceBuilder types); I don't remember who suggested to read strings from Resources (I think is you, Alexander, right?). I'm also planning a global refactoring of exception messages something similar to resources (coupled with CultureInfo) but without any XML (not during compile time or run time). I also want to give more detailed messages that targets developers. Ensure 100% correct english prior for end users (but for developers too). More languages etc.

I'm going to read other threads but these to points are clear to me.

What do you think?

Regards, Giacomo

[alexanderfast]

I don't remember who suggested to read strings from Resources

You're thinking of number #20.

[gsscoder]

Exactly. There's so much threads here now...

Your workaround will be without doubt integrated in the mainstream abstract option. Its functionality I mean.

In (2) regards to exceptions, I was also talking about writing a little helper for managing resources. But in this case, we're talking of strings that lives inside the library and do not relate what a normal developer should take into account (on the counterpart contributors should be care of this!).

Is just about to throw away string literals, refactoring these inside an internal type (that lives in new namespace CommandLine.Internal) and optionally got a subset of functionality that is normally obtained using resx files in Visual Studio (but without using it -> I want to layout from scratch that an model it 100% around library needs).

In the past I was used to employ I nice tool: it eats a special string resource text file (not xml) and spit out C# (or VBNET) source code file with a type that wraps those string and returns it an culture friendly way. If I'm not wrong it was call StringResourceCompiler or something like that...