Re: Overlapping arguments (SOLR-17383)

[Christos Malliaridis]

Thanks Houston for your perspective and sorey for the late response.

I have considered both outcomes and thought that going with the -v for
version is more expected for new users. Usually CLI tools allow something
like "[command] -v" to get quick and easy the version of the CLI tool /
command. In the case of "bin/solr -v", with -v for verbose, it would start
a Solr instance with the default values if I am not mistaken, which may not
be the expected output for new users that use -v to check if the tool is
successfully installed / accessible.

With "version" as argument, like in "bin/solr version", the version turns
into a "tool" and it accepts inputs like flags. I would like to avoid such
tool to avoid further confussion and new ways of getting the same
information in different ways, but we have cases where we might want to get
the version metadata of a solr instance, rather than the CLI tool itself.
For these cases, additional flsgs could influence the output. Whether this
causes more confussion or is to be expected may depend on how the version
information is printed / outputed now and in the future.

It is also worth noting that our current logic parses the -v into the
argument "version" and later executes the VersionTool. This behavior could
be replaced if we wouldn't have a VersionTool or if we follow your
recommendation of using -v for verbose.

So regardless of my proposal of using "-v" for version, your proposal of
using it for verbose is also reasonable.

Therefore, I'd like to get more opinions / perspectives on that, so that we
can decide for a the most suitable resolution and continue with the
improvements.

Best,
Christos


On Fri, 6 Sep 2024, 22:15 Houston Putman,  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
> >  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
> > > , 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)

Re: Overlapping arguments (SOLR-17383)

[David Smiley]

Maybe both?  Meaning, if "-v" is provided, start Solr in verbose mode and
print the version number first.

On Sun, Sep 8, 2024 at 2:34 PM Christos Malliaridis 
wrote:

> Thanks Houston for your perspective and sorey for the late response.
>
> I have considered both outcomes and thought that going with the -v for
> version is more expected for new users. Usually CLI tools allow something
> like "[command] -v" to get quick and easy the version of the CLI tool /
> command. In the case of "bin/solr -v", with -v for verbose, it would start
> a Solr instance with the default values if I am not mistaken, which may not
> be the expected output for new users that use -v to check if the tool is
> successfully installed / accessible.
>
> With "version" as argument, like in "bin/solr version", the version turns
> into a "tool" and it accepts inputs like flags. I would like to avoid such
> tool to avoid further confussion and new ways of getting the same
> information in different ways, but we have cases where we might want to get
> the version metadata of a solr instance, rather than the CLI tool itself.
> For these cases, additional flsgs could influence the output. Whether this
> causes more confussion or is to be expected may depend on how the version
> information is printed / outputed now and in the future.
>
> It is also worth noting that our current logic parses the -v into the
> argument "version" and later executes the VersionTool. This behavior could
> be replaced if we wouldn't have a VersionTool or if we follow your
> recommendation of using -v for verbose.
>
> So regardless of my proposal of using "-v" for version, your proposal of
> using it for verbose is also reasonable.
>
> Therefore, I'd like to get more opinions / perspectives on that, so that we
> can decide for a the most suitable resolution and continue with the
> improvements.
>
> Best,
> Christos
>
>
> On Fri, 6 Sep 2024, 22:15 Houston Putman,  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
> > >  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
> > > > , 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 ano

[RESULT] [VOTE] Release Solr 9.7.0 RC2

[Anshum Gupta]

Thank you everyone who tested the RC and voted.

It's been >72h since the vote was initiated and the result is:

+1  7  (7 binding)
 0  0
-1  0

This vote has *PASSED*.

-Anshum Gupta