In the section on "Arguments and Flags" in
https://clig.dev/#arguments-and-flags, they suggestion that --version is for
Version. And that due to the confusion of -v for Version or Verbose, to use -d
and --debug and skip the verbose concept completely.
I think the --version would only apply to bin/solr, and maybe it would be
worth removing "bin/solr version" as a seperate sub-command, since it is
confusing with the "bin/solr --version" command.
There was thought about extending the "version" command to providing more
information about solr... Like interorogating the running Solr and telling
you lots of stuff... maybe at that point we go with "bin/solr information" as
a command or osmething like that. "bin/solr probe"?
Then we move to -d for debug? And drop "-v" all together?
On Friday, September 6, 2024 at 03:15:56 PM EDT, Houston Putman
<hous...@apache.org> wrote:
Why keep "-v" and "-version" around? I'd much rather keep the very
widely-used "-v"="--verbose".
Only supporting "bin/solr version" makes much more sense to me. And I'm not
even particularly worried about back compat for this one.
- Houston
On Fri, Sep 6, 2024 at 1:10 PM Christos Malliaridis <c.malliari...@gmail.com>
wrote:
> Many thanks to Eric for handling all the conflicts so far and creating PRs
> in an instant.
>
> The next conflict we have in Solr is the -v flag. -v is used for version in
> bin/solr.cmd (explicitly) and SolrCLI, for verbose (with the partly removed
> uppercase variant -V for a special case) in multiple CLI classes, and for
> value in ClusterTool. Ticket SOLR-17442
> <https://issues.apache.org/jira/browse/SOLR-17442> proposes to replace via
> deprecation "verbose" with "debug" (-d and --debug), keep -v for version
> and remove -v for "value". I hope this proposal is reasonable and makes
> sense. Input, opinions and objections are of course welcomed as well.
>
> *P.S. I've read that arguments and flags should be distinguished, even
> though I was using them interchangeably so far for the CLI. What we have
> been referring to so far were CLI flags, so I'll try to use the right
> naming from now on. A nice website with useful information that Eric showed
> me is *https://clig.dev/.
>
> On Fri, Aug 30, 2024 at 7:51 PM Christos Malliaridis <
> c.malliari...@gmail.com> wrote:
>
> > Continuing with the next conflict,
> >
> > We use -p mainly for the port argument and it is currently used in
> > RunExampleTool and SolrExporter as such. -p is also used in ConfigTool
> for
> > --property, in PackageTool for --param, and in PostTool for --params.
> This
> > is more of a "light" conflict, as it does not break any functionality,
> but
> > potentially causes confusion to new users.
> >
> > The port argument is one of the first arguments new users learn when
> > starting Solr, and other tools use -p for port as well. Therefore, I
> > propose to reserve -p for port, deprecate -p in ConfigTool, PackageTool
> and
> > PostTool in version 9.8 and remove it completely in 10.0. This avoids
> false
> > expectations of providing a port number via -p for actions like "solr
> > config" "solr package" or "solr post", which may lead to unwanted
> results.
> > The port argument may then be added like the solr url argument
> (--solr-url)
> > to all tools if necessary.
> >
> > If there are any objections, please let us know. I've created SOLR-17431
> > <https://issues.apache.org/jira/browse/SOLR-17431>, but it can still be
> > resolved and closed if we decide to take a different action.
> >
> > P.S. Since --param in PackageTool and --params in PostTool are used for
> > passing parameters, we can consider in another discussion to deprecate
> and
> > replace --param with --params.
> >
> >
> >
> > On Tue, Aug 27, 2024 at 11:17 PM Christos Malliaridis <
> > c.malliari...@gmail.com> wrote:
> >
> >> Hello everyone,
> >>
> >> In order to start resolving the CLI argument conflicts from
> >> https://issues.apache.org/jira/browse/SOLR-17383, we started to
> >> deprecate (in 9.X) and remove or change (in 10.0/main) the overlapping
> >> arguments. I would like to use this thread for tracking each conflict
> >> resolution.
> >>
> >> A conflict may be a bug or limitation of the CLI, but also just a
> >> possible misinterpretation for new users. Therefore, we should decide
> for
> >> each conflict what action we should take for the upcoming versions of
> Solr.
> >> The current state can be tracked at
> >>
> https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing
> >> (work in progress).
> >>
> >> Starting with -h, it is currently used for printing the help information
> >> (equivalent to --help) and for providing a hostname in
> RunExampleTool.java
> >> (equivalent to --host, in 9.X and main).
> >> I created https://issues.apache.org/jira/browse/SOLR-17423, which
> >> proposes the deprecation of -h for hostname in the context of
> >> RunExampleTool, and the removal of it in future major releases (10.0
> >> ongoing).
> >>
> >> If there are any objections, please let us know.
> >>
> >> Best,
> >> Christos
> >>
> >> On Fri, Jul 26, 2024 at 9:36 PM Christos Malliaridis <
> >> c.malliari...@gmail.com> wrote:
> >>
> >>> Hello devs,
> >>>
> >>> I would like to get some attention on overlapping arguments that I have
> >>> found and documented in SOLR-17383
> >>> <https://issues.apache.org/jira/browse/SOLR-17383>. This was one of my
> >>> "bad experiences" when I started working with Solr, so I think it may
> be
> >>> more important than I thought.
> >>>
> >>> With the great work and progress of Eric Pugh moving parts of the
> >>> scripts to Java and my contribution in finding usages of deprecated
> >>> arguments, I got even more curious to identify and document the
> overlapping
> >>> arguments in both short and long terms.
> >>>
> >>> I am not sure what would be the best way to address this, but I think
> we
> >>> can improve some arguments in various ways, now that we have already
> >>> started deprecating the usage of specific arguments and argument
> formats.
> >>>
> >>> Now that we have moved the argument parsing to Java, we could
> eventually
> >>> make use of Java's inheritance and leverage some arguments like the
> Solr
> >>> URL, --help or --verbose to make them available in all cases if
> applicable.
> >>>
> >>> Best,
> >>> - Christos
> >>>
> >>
>
