Release update

[phlptp]

Update the Readme and the changelog in preparation for a release.

[phlptp]

@henryiii I think it is time to make a release, been over a year since the the last one, and some bigger features in place that should be in a release version. Is there anything else you want in a release? I know you talked about something with Unicode but not sure what exactly that was.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (b8edd50) 100.00% compared to head (3bdebd8) 100.00%.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #974   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           17        17           
  Lines         4546      4546           
=========================================
  Hits          4546      4546           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[phlptp]

@henryiii pinging you again if there is anything else in a release and to check over the changelog.

[henryiii]

The unicode thing I'd like to check before release was here, I think. Basically, now we have (2), (3), and (4):

// 1 (not supported today)
app.ensure_utf8(argc, argv);
CLI11_PARSE(app);  // Uses stored argv vector on all platforms

// 2 (almost supported in main only - missing argc)
argv = app.ensure_utf8(argc, argv);
CLI11_PARSE(app, argc, argv);  // Uses produced argv vector

// 3 (supported in all versions)
CLI11_PARSE(app, argc, argv); // Not unicode

// 4 (supported in main only)
CLI11_PARSE(app); // Not portable, but unicode

I'm not fond of (4), since it requires non-standard trickery that sometimes fails, and the reluctance to release is because we'd be making that a supported way to operate. We could get rid of this and add (1), which is a bit more code, but doesn't have any non-standard trickery and is still simpler than (2).

We could also leave it as is. We could also just remove (4), and only allow (2) and (3), as more ways to do things just to save a few characters isn't necessarily better.

[henryiii]

Actually, we currently have:

argv = app.ensure_utf8(argv);
CLI11_PARSE(app, argc, argv);  // Uses produced argv vector

Which is not compatible with (1) at all.

[henryiii]

Here are the possibilities, IMO:

1. Change argv = app.ensure_utf8(argv); into argv = app.ensure_utf8(argc, argv); and have it store argc/argv in App (on UNIX), so that CLI11_PARSE(app) no longer does non-standard magic to get these values on UNIX. Remove the magic version of CLI11_PARSE(app) (without running ensure_utf8 first).
2. Remove CLI11_PARSE(app); and the only way to do this is with argv = app.ensure_utf8(argv);.
3. Leave as is; two ways to get unicode (one being shorter but not working on some systems).

[phlptp]

Longer term we should figure out the best means of not using MACROS as recommended. It does serve a purpose so fine leaving it for now. But in my opinion 1 and 4 should not be supported macros, they hide too much. I don't see a good means of getting rid of them completely in C++11 so there should only be 1 form of the macro, that is fairly simple.

[phlptp]

What we are really talking about whether to keep the parse() method on app. That is what allows the macro to work with CLI11_PARSE(app) with no arguments.

[henryiii]

Yes, it's really about .parse(...). The macros are always easy to replace, it's just 4 lines, it's just a bit annoying to have to type out the four lines. It's also nice as eventually I want to try to avoid requiring exception catching, and when that happens, CLI11_PARSE can still be supported, but the thing it expands to will change.

So you like Option 2?

[phlptp]

I think that would be my preference but I don't use much unicode,

[phlptp]

Looking at it, I think the simplest immediate solution would be rename the parse() method to something else e.g. parse_from_cli_args or something to that effect to match something like parse_from_stream, which does the parsing but does something a little different than the typical parsing.

[henryiii]

I'm looking at the code removable if we drop the no-argument parse() (this includes dropping CLI11::argc() and CLI11::argv()). The ugliest code is the Windows code, which we have to keep for any unicode support (app.ensure_utf8), so nothing changes there. The macOS removal drops *_NSGetArgc usage, which I assume is pretty stable; IMO the main issue is the Linux use of fp_unique(std::fopen("/proc/self/cmdline", "r"), deleter);, which can fail if /proc is missing (#845), such as is the case if a user calls chroot. (Plus I'm not sure how this handles other operating systems, like FreeBSD and such?)

IMO, having CLI11_PARSE(app) but having hidden pitfalls that an application user could fall into is not a great idea, when we could instead just have a app.ensure_utf8 call and no pitfalls. It's CLI11's fault if a user of a tool using CLI11 reports that their application fails due to chroot usage, for example. I don't even mind adding it to all example usages of CLI11; it's pretty obvious from the name that you could remove it to remove unicode support.

[henryiii]

(Currently distracted by fixing Catch2 3 support, which seems to have broken)

[phlptp]

@henryiii any chance we can finish this up this week. I am working on a release for another project and would be nice to include an actual release of CLI11 in it.

[henryiii]

We can try. I’m likely to not have time tomorrow, but Thursday Friday I should. I’m still very worried about Unicode and want to strip the “simple” form out before release. I’d also like to know if it supports wmain on windows, and what happens if you aren’t expecting Unicode.

[phlptp]

Anything we need to change in this PR? @henryiii

[henryiii]

I'll try to do final review this weekend, release on Monday.