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] > >
