+1 I think that having separate CHANGES.txt files for the different parts of Solr would be great. If you are looking for certain changes you would generally know which module to go to.
Some items that have a more sweeping impact would be listed in both I am ambivalent on having a separate CHANGES.txt for SolrJ, as long as major changes are included in the main CHANGES.txt. In general it's easy to add an entry to every applicable CHANGES.txt, no matter which module the change was made in. - Houston On Sat, Nov 21, 2020 at 1:34 AM David Smiley <[email protected]> wrote: > What of Docker changes? And beyond direct changes to Dockerfile + > scripts, it could feature particular notable changes to the server that are > particularly noteworthy... like hypothetical improvements to solr home / > core root dir etc. configuration. > > Even if Contribs/Modules are not separated out of the repo *yet* (even if > they hypothetically never leave), I think it's desirable to separate their > CHANGES.txt in master now. > > RE SolrJ -- I know it's used heavily in the server side; this one is more > debatable than the others and I don't have a strong opinion. Some items > that have a more sweeping impact (e.g. HTTP2) would be listed in both but > the difference is that the SolrJ side would have a more user-facing > purpose, mentioning SolrClient subclasses that are pertinent to draw > attention to compatibility or new classes users should know about. This > kind of stuff is maybe too detailed to bother putting in > solr-upgrade-notes.adoc but would not be to SolrJ's dedicated CHANGES.txt. > On server CHANGES.txt, we tend to be vague. If SolrJ is changed for > something that has more to do with server-side (e.g. SOLR-14691 "Metrics > Reporting Should Avoid Creating Objects" which changed some utils in > SolrJ), then it ought not to be listed in SolrJ's proposed CHANGES.txt. > Admittedly there may be more cumulative CHANGES.txt maintenance between the > two. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Nov 20, 2020 at 9:17 PM Ishan Chattopadhyaya < > [email protected]> wrote: > >> I think whatever we don't ship in the main tarball today should stay >> separate. Going forward, when we stop shoving the extra modules (contribs) >> into the main distro, we can separate out their changelogs. However, I feel >> SolrJ changes should stay with Solr changes since it is also used heavily >> in the server side. >> >> On Sat, 21 Nov, 2020, 3:39 am David Smiley, <[email protected]> wrote: >> >>> I was about to merge a PR pertaining to Solr's new Docker module when it >>> occurred to me that I ought to add a CHANGES.txt entry. But, for Solr >>> users (which includes me and everyone reading this), it's annoying to have >>> to go to Solr's all-encompassing CHANGES.txt to find Docker upgrade >>> notes, which is a distinct way of running Solr. I think the same could be >>> said for our contribs, and perhaps even SolrJ, which is another distinct >>> consumable. The idea of separated CHANGES.txt aligns well with contribs >>> being further isolated (see both the discussion on separate git repos for >>> them, and also the discussion of getting rid of "dist" (each contrib's jar >>> goes in its own folder; keeps to itself)). >>> >>> Solr's root /CHANGES.txt could at the very top reference the other >>> CHANGES.txt files. >>> >>> WDYT? >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>
