Somewhat bigger scope: SOLR-14149 - Remove non-changes from CHANGES.txt <https://issues.apache.org/jira/browse/SOLR-14149>
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Dec 24, 2019 at 12:33 PM David Smiley <[email protected]> wrote: > The "new features + upgrade notes in a single place" page in the ref guide > seems to me an odd place to put the current versions of major components. > Seems out of scope. > https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html > > > "I love “Solr System Requirements”" > > LOL > > This page, "solr-system-requirements.adoc" seems to me the right place to > specify ZooKeeper's current version. No need to mention Jetty; users don't > install that. > > I'll file a JIRA issue. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Dec 24, 2019 at 12:19 PM Cassandra Targett <[email protected]> > wrote: > >> +1 to removing from CHANGES.txt, but I think we should really try to >> publish them somewhere instead of asking people to look for .jars. >> >> If we were to go the way I’ve been advocating to go - to have a single >> page in the Ref Guide for each release that includes the new features + >> upgrade notes in a single place instead of two - it would be really trivial >> to publish the versions for the major components on the same page. Most of >> them already exist as Guide build parameters already, a single place would >> make it less likely they're broken for 2 releases (thanks Jan for fixing >> that), and it is very little effort to add new ones as needed. >> >> Cassandra >> On Dec 24, 2019, 8:37 AM -0600, Erick Erickson <[email protected]>, >> wrote: >> >> I started out strongly negative on this, since the idea of just looking >> at the jar file names presupposed you know _where_ to look in the first >> place. >> >> Then realized jar files are a mess, just ask Dawid. There are 272 jar >> files in the 8.3 distro, scattered all over the place. This may get better >> when we move to Gradle, but even then there will still be a lot of jar >> files. >> >> For instance, there are three copies of slf4j-api-1.7.24.jar in the >> distro, which one is important? At least they all have the same version so >> that’s something. >> >> ./dist/solrj-lib/slf4j-api-1.7.24.jar >> ./server/lib/ext/slf4j-api-1.7.24.jar >> ./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar >> >> Zookeeper is in ./dist/solrj-lib/ and >> ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one >> is used? Which one should I use if I want to run an external Zookeeper? >> Gaaaaahhhhh. >> >> So the more I thought about it, the more I realized it’s just impossible >> to untangle that in the CHANGES.txt file, and the point of specifying which >> Tika version is well taken (why that and not others?). The only component >> that I think _shouldn’t_ be something a user needs to dig for is Zookeeper >> since we recommend that they install an external ensemble. And just putting >> Zookeeper in CHANGES.txt is awkward. >> >> For that matter, why to we specify the JVM in a different place in >> CHANGES.txt? That should be moved to a system-requirements page too IMO. >> I’d frankly rather go find the one place the relevant information is than >> reconcile multiple, possibly conflicting sources. >> >> So after dithering for far too long, +1 to rip this out of CHANGES.txt. >> We should take the JVM out of CHANGES.txt too. Let’s put this in a system >> requirements page in the ref guide and point to it from CHANGES.txt. I >> think we should just point here: https://lucene.apache.org/solr/guide/ >> which lets them pick the version of the ref guide rather than to a specific >> version on the theory that it’s one less thing to keep synchronized. >> Perhaps guiding them to look at “System requirements>>Solr System >> Requirements”. (and, BTW, I love “Solr System Requirements”, when I was >> working on the page I wanted to start with “start a few billion yeas ago >> with a lot of interstellar dust and gas and...”). >> >> On Dec 24, 2019, at 6:56 AM, Jan Høydahl <[email protected]> wrote: >> >> Jetty version is printed early in the logs so should be easy to find if >> you don’t want to check the sources. >> >> Looking in RefGuide for ZK version, there seems to be a bug, see >> https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper >> The variable ${org.apache.zookeeper.version} is not expanded in the >> asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146 >> >> Jan >> >> 24. des. 2019 kl. 06:48 skrev David Smiley <[email protected]>: >> >> +1 to all that Jan; your response was very thoughtful. >> >> Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR >> option went away, we now think of Jetty as a component of Solr instead of >> something we deploy to, at least in communication to our users. If an >> advanced user wants to mess with Jetty configuration, I'm sure he/she will >> figure it out. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <[email protected]> >> wrote: >> In the binary distro there is no version.properties... >> >> Perhaps just keep Jetty version in CHANGES? >> The Zookeeper version is useful if you want to choose an external ZK to >> install, but the refGuide should help here. >> Unfortunately we do not link to the Reference Guide from README in Solr >> binary download so that info is not readily available either. >> I think we should link to online ref-guide both from README and from >> online docs https://lucene.apache.org/solr/8_2_0/ >> Also, recommended ZK version for Cloud should be part of >> SYSTEM_REQUIREMENTS.txt, i.e. >> https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ? >> >> Jan >> >> 23. des. 2019 kl. 22:49 skrev David Smiley <[email protected]>: >> >> Our CHANGES.txt has "Versions of Major Components" as follows: >> >> Versions of Major Components >> --------------------- >> Apache Tika 1.23 >> Carrot2 3.16.0 >> Velocity 2.0 and Velocity Tools 3.0 >> Apache ZooKeeper 3.5.5 >> Jetty 9.4.24.v20191120 >> >> I think we should just eliminate this. Some of this stuff is really in >> our contribs, and some of those will be ejected soon. But even for the >> others, this sort of thing is pretty easy to figure out (e.g. >> version.properties or simply *look* at the jar names). >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
