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