Propose eliminate "Versions of Major Components"

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Propose eliminate "Versions of Major Components"

david.w.smiley@gmail.com
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
Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

Jan Høydahl / Cominvent
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 <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

david.w.smiley@gmail.com
+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


On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <[hidden email]> 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 <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

Jan Høydahl / Cominvent
Jetty version is printed early in the logs so should be easy to find if you don’t want to check the sources.

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 <[hidden email]>:

+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


On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <[hidden email]> 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 <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

Erick Erickson
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 <[hidden email]> 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 <[hidden email]>:
>>
>> +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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

Cassandra Targett
+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 <[hidden email]>, 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 <[hidden email]> 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 <[hidden email]>:

+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 <[hidden email]> 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 <[hidden email]>:

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

david.w.smiley@gmail.com
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


On Tue, Dec 24, 2019 at 12:19 PM Cassandra Targett <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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 <[hidden email]>:

+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 <[hidden email]> 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 <[hidden email]>:

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

david.w.smiley@gmail.com
Somewhat bigger scope:

On Tue, Dec 24, 2019 at 12:33 PM David Smiley <[hidden email]> 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


On Tue, Dec 24, 2019 at 12:19 PM Cassandra Targett <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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 <[hidden email]>:

+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 <[hidden email]> 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 <[hidden email]>:

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

Erick Erickson
Does it make sense to mention where to look for the jars Solr uses? Or maybe just where the “major components” live?

The problem is that even leaving out things like contribs and test, it’s still confusing:

dist
dist/solrj-libs
server/solr-webapp/webapp/WEB-INF/lib
server/lib



> On Dec 24, 2019, at 12:44 PM, David Smiley <[hidden email]> wrote:
>
> Somewhat bigger scope:
> SOLR-14149 - Remove non-changes from CHANGES.txt
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Dec 24, 2019 at 12:33 PM David Smiley <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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 <[hidden email]>:
>>>>
>>>> +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 <[hidden email]> 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 <[hidden email]>:
>>>>>
>>>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Propose eliminate "Versions of Major Components"

Dawid Weiss-2
In reply to this post by Erick Erickson
> Then realized jar files are a mess, just ask Dawid.

It is a mess. I don't quite understand many of these dependencies.

We can generate a file with all (or a subset) of versions from actual
dependency list during build time (gradle). This isn't a problem -- in
fact, it's already being done for solr manual.

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]