Robert Liebowitz

For my use case, I actually prefer the behavior that flags must be placed specifically next to their declaration site. To give an example of why this is important—I have...

I'm actually still on v1. I'm not sure what the current behavior is for this, or what the impetus for changing it was.

I'm not sure that we have the maintenance resources to push forward with a 3.X release right now. But I don't think we need to make a breaking change to...

> Also I was kind of surprised that .Before prints error together with the usage template if the error is returned Good call there. As of https://github.com/urfave/cli/pull/1117 that is no...

@lynncyrin if you had any thoughts here

Improve testability of `*cli.Context`. A couple of potential options: - Create a `cli.NewTestContext` or similar that could give us the ability to configure private fields like `flagSet` that are currently...

> taking a pass at reducing our public api surface, so there's less ways we can accidentally break people's code Closed a while back due to staleness, but removing unused...

Drop explicit support for the `MultiError` interface in `HandleExitCoder`, and instead make the private `multiError` type implement `ExitCoder`. Right now `MultiError` as an interface seems to be supported specifically for...

Thank you for your interest and contributions, I really appreciate the effort you've put in so far. > Is there any appetite for re-organizing code ? Absolutely. If there are...

The status of a 3.X release is pretty unlikely right now, since the maintenance overhead is probably higher than we have folks who can support it (although we haven't dropped...