+1 Fully agree, repeating a few subjective "major new" features there won't buy us anything really.
Jan > 18. okt. 2026 kl. 19:01 skrev David Smiley <[email protected]>: > > Our "major-changes-in-solr-10.adoc" (and similar) are under the "upgrade > notes" directory of the Solr ref guide. They each have the following > heading preface: > >> This page highlights the most important changes including new features > and changes in default behavior as well as previously deprecated features > that have now been removed. > > I think the most important information on these pages are the upgrade > aspect -- what should a user know about when upgrading to a particular Solr > version. > > But including "new features" is debatable. It's extra work to include this, > takes a subjective decision, and can be forgotten. The distinction between > forgotten and deciding not worthiness is indiscernible. I suspect I > advocated for this scope years ago. It's certainly good to be aware of new > things with each release but we already have the "release highlights" for > each release, which does this. That is published with each release. > > Proposal: The major changes pages should only have information related to > upgrading. Upon every release, we can add a *link* to the release > highlights. > > Challenge/issues: The nice HTML form of the release highlights is one news > entry with an anchor tag on an ever-growing/expanding list of whatever we > categorize as "news" (mostly new releases + CVE it seems). The URL -- ex: > https://solr.apache.org/news.html#apache-solrtm-9110-available doesn't seem > particularly "durable". Meanwhile, our HTML Changelog is quite durable: > https://solr.apache.org/docs/10_0_0/changes/Changes.html I could imagine a > standalone HTML release highlights page... but wouldn't it be a nicer user > experience to integrate that into the HTML changelog at the top? One > integrated page for "highlights" + the actual changelog details. > > Heck, perhaps even release-specific upgrade notes are best placed on this > page somehow (vs the ref guide). --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
