Should we switch to a structured format, instead of current format that
tools struggle to convert.
Something that one could push into Solr would have been nice...
Regards,
Alex
On Mon., Nov. 23, 2020, 4:47 p.m. David Smiley, <dsmi...@apache.org> wrote:
> I pushed a commit to a PR for the prometheus exporter that includes a
> CHANGES.md
>
> https://github.com/apache/lucene-solr/pull/1972/commits/bec84ce2a1d60480ce0c54b78e83a70f83e7b058
> and likewise for a commit to a PR for the docker module:
>
> https://github.com/apache/lucene-solr/pull/2083/commits/540f8117153d12bd13441326035820f97084878a
>
> * I chose the Markdown format. This is an opportune time to switch. This
> meant changing "==== 9.0 ====" to "9.0" then "======" beneath it, but
> otherwise, no changes!
> * I chose to start this for 9.0. Any changes prior to 9.0 I think should
> continue to do things as we have been doing things historically.
> * I considered updating dev-tools/scripts/addVersion.py but ultimately
> elected not to. I think the rate of changes in each module will be low
> enough that it's not a big deal to maintain it manually. Plus, I confess
> I'm less motivated to touch Python ;-) but I'd be more than happy to see
> someone automate this.
>
> If this is agreeable, Solr's master CHANGES.txt ought to have references
> to CHANGES.md for contribs & Docker.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Nov 23, 2020 at 11:56 AM Houston Putman <houstonput...@gmail.com>
> wrote:
>
>> +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 <dsmi...@apache.org> 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 <
>>> ichattopadhy...@gmail.com> 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, <dsmi...@apache.org> 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
>>>>>
>>>>
