diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000000..e69de29bb2 diff --git a/404.html b/404.html new file mode 100644 index 0000000000..c3c6093f56 --- /dev/null +++ b/404.html @@ -0,0 +1,1319 @@ + + + +
+ + + + + + + + + + + + + + ++++
This document is no longer being actively maintained. Please see the +releases page for all release notes +and related hypermedia for releases
>= 1.22.5
,>= 2.3.0
.
ATTN: This project uses semantic versioning.
+View unreleased 2.X series changes.
+These release notes were written for the git hash d648edd48d89ef3a841b1ec75c2ebbd4de5f748f
+StringSliceFlag
in urfave/cli/pull/1078 via @davidsbondHideHelpCommand
. While HideHelp
hides both help
command and --help
flag, HideHelpCommand
only hides help
command and leave --help
flag as-is in urfave/cli/pull/1083 via @AkihiroSudaContext
regression introduced in v2.1.0
in urfave/cli/pull/1014 via @lynncyrinThese release notes were written for the git hash ae84df4cef4a2a6f1a0cb1d41ea0f3af8755e5a8
+App.Run
to use an optional context for timeouts and cancellation in urfave/cli/pull/975 via @marwan-at-workValue
accessor in urfave/cli/pull/741 via @corruptmemoryThe V2 changes were all shipped in urfave/cli/pull/892, which was created with the effort of over a dozen participants! They are:
+@asahasrabuddhe, @meatballhat, @jszwedko, @lynncyrin, @AudriusButkevicius, @saschagrunert, @rliebz, @johnweldon, @nlewo, @grubernaut, @OneOfOne, @VMitov, @cbranch, @marwan-at-work, @uudashr, @bfreis
+NewStringSlice
and NewIntSlice
for creating their related typesFloat64SliceFlag
for unmarshaling a list of floats from the userContext.Lineage
to get all contexts from current up to globalContext.LocalFlagNames
to get the flag names from only the current contextBoolFlag.Value
to handle both default-false and default-trueIsSet
method to the Flag
interface which allows us to detect whether or not a flag has been setContext.FlagNames
now returns all flags in the context lineageContext.IsSet
now considers the full context lineage&StringSlice{...string}
or &IntSlice{...int}
.Action
func signatureApp.Author
, App.Email
, and Command.ShortName
fieldsContext.Global*
methods, as the non-global versions now traverse up
+ the context lineage automatically.Context.Parent
method, as this is now available via Context.Lineage
BoolTFlag
and related code, as this is now available via BoolFlag.Value
View unreleased 1.22.X series changes.
+context.IsSet()
returns true
or false
correctly regardless of whether the short name or the full name of the flag is passed to it in urfave/cli/pull/978 via @asahasrabuddheDocGenerationFlag.TakesValue()
docstring in urfave/cli/pull/902 via @benmooseHelpPrinter
and CustomHelpPrinter
behaviors in urfave/cli/pull/912 via @rliebzGo 1.10
add support for Go 1.13
in urfave/cli/pull/885 via @asahasrabuddheapp.ExitEventHandler
in urfave/cli/pull/856 via @FaranIdo1.10
, 1.11
, 1.12
in urfave/cli/pull/843 via @lafriksUseShortOptionHandling
for combining short flags in urfave/cli/pull/735 via @rliebzTakesFile
indicator to flag in urfave/cli/pull/851 via @saschagrunertEnvVar
in urfave/cli/pull/687 via @joshuarubinSkipFlagParsing
behavior in urfave/cli/pull/697 via @jszwedkoShortOptions
and SkipArgReorder
in urfave/cli/pull/686 via @baudeInputSource
to v1 in urfave/cli/pull/598 via @jszwedkoExitError
handler function in urfave/cli/pull/628 via @phinnaeusHandleExitCoder
is now correctly iterates over all errors in
+ a MultiError
. The exit code is the exit code of the last error or 1
if
+ there are no ExitCoder
s in the MultiError
.Usage
, Description
, ArgsUsage
, OnUsageError
correctly
+ propagatedErrWriter
is now passed downwards through command structure to avoid the
+ need to redefine itCommand
context into OnUsageError
rather than parent context so that
+ all fields are availableBefore
funcs are no longer double printedUsageText
in the help templates for commands and subcommands if
+ defined; otherwise build the usage as before (was previously ignoring this
+ field)IsSet
and GlobalIsSet
now correctly return whether a flag is set if
+ a program calls Set
or GlobalSet
directly after flag parsing (would
+ previously only return true
if the flag was set during parsing)OsExiter
. This exiting behavior was introduced in 1.19.0, but was
+ determined to be a regression in functionality. See the
+ PR for discussion.CommandsByName
type was added to make it easy to sort Command
s by name,
+ alphabeticallyaltsrc
now handles loading of string and int arrays from TOMLApp
via
+ CustomAppHelpTemplate
App
to be used with
+ CustomAppHelpTemplate
via ExtraInfo
HelpFlag
, VersionFlag
, and BashCompletionFlag
changed to explicitly be
+ cli.Flag
s allowing for the use of custom flags satisfying the cli.Flag
+ interface to be used.ActionFunc
as
+ the Action
for a command would cause it to error rather than calling the
+ function. Should not have a affected declarative cases using func(c
+ *cli.Context) err)
.--generate-bash-completion
immediately after a flag that takes an argument.
+ Previously it call the application with --generate-bash-completion
as the
+ flag value.FlagsByName
was added to make it easy to sort flags (e.g. sort.Sort(cli.FlagsByName(app.Flags))
)Description
field was added to App
for a more detailed description of
+ the application (similar to the existing Description
field on Command
)go generate
altsrc
loaderSkipArgReorder
was added to allow users to skip the argument reordering.
+ This is useful if you want to consider all "flags" after an argument as
+ arguments rather than flags (the default behavior of the stdlib flag
+ library). This is backported functionality from the removal of the flag
+ reordering in the unreleased version
+ 2ErrorFormatter
), the errors will
+ be formatted during output. Compatible with pkg/errors
.""
would be skipped rather than their value used).App.Writer
defaults to stdout
when nil
panic
ingApp.Metadata
is initialized automatically now (previously was nil
unless initialized)-h
is provided to a subcommandcontext.(Global)IsSet
now respects environment variables. Previously it
+ would return false
if a flag was specified in the environment rather than
+ as an argumentaltsrc
s import paths were updated to use gopkg.in/urfave/cli.v1
. This
+ fixes issues that occurred when gopkg.in/urfave/cli.v1
was imported as well
+ as altsrc
where Go would complain that the types didn't match./runtests
test runner with coverage tracking by defaultUintFlag
, Uint64Flag
, and Int64Flag
types and supporting codehelp
subcommand when using CommandCategories
panic
s that occur within the Action
s themselves when
+ detecting the signature of the Action
fieldcli.DefaultFlagStringFunc
context.GlobalBoolT
was added as an analogue to context.GlobalBool
Hidden: true
-- this will hide the
+ commands in help outputFloat64Flag
, IntFlag
, and DurationFlag
default values are no longer
+ quoted in help text output.(default: {value})
strings following usage when a
+ default value can be (reasonably) detected.IntSliceFlag
and StringSliceFlag
usage strings are now more consistent
+ with non-slice flag typescli
since they can trust
+ that a 0 exit code indicated a successful execution.Hidden
field on all flag struct types to omit from generated help textBashCompletionFlag
(--enable-bash-completion
) is now omitted from
+generated help text via the Hidden
fieldHandleAction
and HandleExitCoder
App.Metadata
map for arbitrary data/state managementSet
and GlobalSet
methods on *cli.Context
for altering values after
+parsing.App.Action
and Command.Action
now prefer a return signature of
+func(*cli.Context) error
, as defined by cli.ActionFunc
. If a non-nil
+error
is returned, there may be two outcomes:cli.ExitCoder
, then os.Exit
will be called
+automaticallyApp.Run
Action
with the legacy return signature of
+func(*cli.Context)
will produce a deprecation message to stderrAction
that is not a func
type will produce a non-zero exit
+from App.Run
Action
func that has an invalid (input) signature will
+produce a non-zero exit from App.Run
cli.App.RunAndExitOnError
, which should now be done by returning an error
+that fulfills cli.ExitCoder
to cli.App.Run
.cli.App.Action
of func(*cli.Context)
, which should now have a return
+signature of func(*cli.Context) error
, as defined by cli.ActionFunc
.*cli.Context.GlobalFloat64
methodCategorizedHelp
and Categories
on app.filepath.Base
instead of path.Base
in Name
and HelpName
.HideVersion
set.NArg
method on context.USAGE
section of help output.panic
from default help printer func.Before
/After
at command level when no subcommands.-
argument causing flag reordering.path.Base
in Name
and HelpName
GetName
on flag types.tip
in Travis CI config.ArgsUsage
at app and command level for help text flexibility.HideHelp
and HideVersion
in App.Run
.FullName
on command with accompanying help output update.$PROG
in bash completion.Copyright
at app level.Parent
func at context level to walk up context lineage.Before
/After
funcs.HelpPrinter
signature includes output writer.Writer
when running command as app.NumFlags
at context level.Aliases
at command level.ShortName
at command level.Author
and Email
fields.Names
/Aliases
.After
hook func support at app and command level.-h / --help
flags, but not help
subcommand.--
.ParseInt
instead of ParseUint
for int environment var values.0
as base when parsing int environment var values.Stdout
on app for output redirection.ShowCommandHelp
.-v / --version
flag made optional.FlagNames
at context level.VersionPrinter
var for more control over version output.AUTHOR
section in default app help template.DurationFlag
type.Author
, Email
, and Compiled
metadata on app.Before
hook func support at app and command level.CommandNotFound
func support at app level.GenericFlag
type.Float64Flag
type.BoolTFlag
type.IsSet
flag helper on context.HelpPrinter
var for more control over help output.help
flag in default app flag set and each command flag set.StringSliceFlag
type and supporting StringSlice
type.IntSliceFlag
type and supporting IntSlice
type.In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, gender identity and expression, level of experience, +education, socio-economic status, nationality, personal appearance, race, +religion, or sexual identity and orientation.
+Examples of behavior that contributes to creating a positive environment +include:
+Examples of unacceptable behavior by participants include:
+Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior.
+Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful.
+This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting urfave-governance@googlegroups.com, a members-only group +that is world-postable. All complaints will be reviewed and investigated and +will result in a response that is deemed necessary and appropriate to the +circumstances. The project team is obligated to maintain confidentiality with +regard to the reporter of an incident. Further details of specific enforcement +policies may be posted separately.
+Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership.
+This Code of Conduct is adapted from the Contributor Covenant, version 1.4, +available at https://www.contributor-covenant.org/version/¼/code-of-conduct.html
+ + + + + + + + + + + + + + + + + + + + +Welcome to the urfave/cli
contributor docs! This goal of this document is to help those
+interested in joining the 200+ humans who have contributed to this project over the years.
++As a general guiding principle, the current maintainers may be notified via the +@urfave/cli GitHub team.
+
All of the current maintainers are volunteers who live in various timezones with +different scheduling needs, so please understand that your contribution or question may +not get a response for many days.
+The urfave/cli
project strives to strictly adhere to semantic
+versioning. The active development branches and the
+milestones and import paths to which they correspond are:
main
branch¶https://github.com/urfave/cli/tree/main
+The majority of active development and issue management is targeting the main
branch,
+which is currently in alpha.
v3.x
github.com/urfave/cli/v3
The main
branch includes tooling to help with keeping track of v3.x
series backward
+compatibility. More details on this process are in the development workflow section below.
v1
branch¶https://github.com/urfave/cli/tree/v1
+The v1
branch is no longer maintained.
v1.22.x
github.com/urfave/cli
v2-maint
branch¶https://github.com/urfave/cli/tree/v2-maint
+The v2-maint
branch MUST only receive bug fixes in the v2.23.x
series. There is no
+strict rule regarding bug fixes to the v3.x
series being backported to the v2.23.x
+series.
v2.23.x
github.com/urfave/cli/v2
Most of the tooling around the development workflow strives for effective
+dogfooding. There is a top-level
+Makefile
that is maintained strictly for the purpose of easing verification of one's
+development environment and any changes one may have introduced:
make
+
Running the default make
target (all
) will ensure all of the critical steps are run to
+verify one's changes are harmonious in nature. The same steps are also run during the
+continuous integration
+phase.
In the event that the v3diff
target exits non-zero, this is a signal that the public API
+surface area has changed. If the changes are acceptable, then manually running the
+approval step will "promote" the current go doc
output:
make v3approve
+
Because the generate
step includes updating godoc-current.txt
and
+testdata/godoc-v3.x.txt
, these changes MUST be part of any proposed pull request so
+that reviewers have an opportunity to also make an informed decision about the "promotion"
+step.
The documentation in the docs
directory is automatically built via mkdocs
into a
+static site and published when releases are pushed (see RELEASING). There
+is no strict requirement to build the documentation when developing locally, but the
+following make
targets may be used if desired:
# install documentation dependencies with `pip`
+make ensure-mkdocs
+
# build the static site in `./site`
+make docs
+
# start an mkdocs development server
+make serve-docs
+
Please feel free to open a pull request to fix a bug or add a feature. The @urfave/cli +team will review it as soon as possible, giving special attention to maintaining backward +compatibility. If the @urfave/cli team agrees that your contribution is in line with the +vision of the project, they will work with you to get the code into a mergeable state, +merged, and then released.
+Those with a history of contributing to this project will likely be invited to join the +@urfave/cli team. As a member of the @urfave/cli team, you will have the ability to fully +administer pull requests, issues, and other repository bits.
+If you feel that you should be a member of the @urfave/cli team but have not yet been
+added, the most likely explanation is that this is an accidental oversight! .
+Please open an issue!
Releasing small batches often is backed by +research as part of the +virtuous cycles that keep teams and products healthy.
+To that end, the overall goal of the release process is to send
+changes out into the world as close to the time the commits were
+merged to the main
branch as possible. In this way, the community
+of humans depending on this library are able to make use of the
+changes they need quickly, which means they shouldn't have to
+maintain long-lived forks of the project, which means they can get
+back to focusing on the work on which they want to focus. This also
+means that the @urfave/cli team should be able to focus on
+delivering a steadily improving product with significantly eased
+ability to associate bugs and regressions with specific releases.
In the main
or v2-maint
branch, the current version is always
+available via:
git describe --always --dirty --tags
+
NOTE: if the version reported contains -dirty
, this is
+indicative of a "dirty" work tree, which is not a great state for
+creating a new release tag. Seek help from @urfave/cli teammates.
For example, given a described version of v2.4.7-3-g68da1cd
and a
+diff of v2.4.7...
that contains only bug fixes, the next version
+should be v2.4.8
:
git tag -a -s -m 'Release 2.4.8' v2.4.8
+git push origin v2.4.8
+
The tag push will trigger a GitHub Actions workflow and will be +immediately available to the Go module mirror, index, and +checksum database. The remaining steps +require human intervention through the GitHub web view although +automated solutions +exist that may be +adopted in the future.
+Choose a tag
select control and select v2.4.8
Write
tab below, click the Auto-generate release notes
buttonPublish release
buttonThis was not always true. There are many lightweight git + tags present in the repository history. ↩
+This was not always true. The
+ docs/CHANGELOG.md
document used to be
+ manually maintained. Relying on the automatic release notes
+ generation requires the use of merge commits as opposed to
+ squash merging or rebase merging. ↩
Hello and thank you for your interest in the urfave/cli
security
+policy!
Version | +Supported | +
---|---|
>= v2.3.x |
+|
< v2.3 |
+|
>= v1.22.x |
+|
< v1.22 |
+
Please disclose any vulnerabilities by sending an email to:
+urfave-security@googlegroups.com
+You should expect a response within 48 hours and further
+communications to be decided via email. The urfave/cli
maintainer
+team comprises volunteers who contribute when possible, so please
+have patience
The v1.22.x
series will receive bug fixes and security
+ patches only. ↩