I'd rather not scope-creep my proposal here further. Granted I ventured into TXT -> Markdown.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Nov 24, 2020 at 9:37 AM Alexandre Rafalovitch <[email protected]> wrote: > And - afterthought - if there is an easily parsable format, the parser > could even run at the commit time on GitHub to make sure that issue > numbers are correct, names are included and formatting is not broken. > > Regards, > Alex. > > On Mon, 23 Nov 2020 at 19:38, Alexandre Rafalovitch <[email protected]> > wrote: > > > > 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, <[email protected]> > 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 < > [email protected]> 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 <[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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
