Eric Pugh

> I have been thinking about adding a deprecation-feature to commons-cli, such that you could construct an Option: > > ```java > Option o = Option.builder("n").longOpt("new-long").deprecatedOpt("oldShort").deprecatedLongOpt("oldLong") > ... > String...

> > I have been thinking about adding a deprecation-feature to commons-cli, such that you could construct an Option: > > ```java > > Option o = Option.builder("n").longOpt("new-long").deprecatedOpt("oldShort").deprecatedLongOpt("oldLong") > >...

What do folks think about moving forward with this as is, and then adding the deprecations when commons-cli comes out....

https://github.com/apache/commons-cli/pull/252 replaced what I proposed and was merged. Now waiting on a release!

Waiting for the upcoming commons cli 1.8.0 to come out with nicer handling of deprecated options.

@janhoy I ran a bit out of steam while waiting for 1.8.0, please do feel free to continue to push this PR along ;-).

> I had a thought now that `bin/solr` supports a remote Solr cluster with `--solr-url`. We currently support `solr version` which prints the version from `SolrVersion.java`, i.e. the client version....

thanks for tackling those.. I would love to get more of the string parsing out of the scripts for solr.. I went back and looked at them, and I think...

Hey all.. so, just got all green on the checks! I'm wondering, how many of the parameters do we want to have deprecation for... We have it for solr url...

chatted with @gerlowskija and the plan is to mark all changed features as Deprecated, not just the solrurl and zkhost, for 9.x, so your scripts don't break in 9.6 to...