Historical reasons for those names, all earlier links would break if we re-purposed the news.html address :)
Jan > 21. okt. 2026 kl. 14:24 skrev Eric Pugh <[email protected]>: > > > > On 2026/10/21 06:36:25 Jan Høydahl wrote: >> But that's exactly what we have, isn't it? https://solr.apache.org/posts.html >> >> And those release highlight news is for people to learn about features in a >> new release. It links to major-changes ref-guide, which we now propose to be >> a pure upgrade note, not changes as in new features; they can instead link >> to the detailed Changes.html page for the full list of changes. >> >> Jan >> >>> 20. okt. 2026 kl. 15:35 skrev Eric Pugh via dev <[email protected]>: >>> >>> Maybe we just have a single news page that points to detailed pages? >>> https://rubyonrails.org/category/news >>> >>> Then each news item could go as deep as we want? >>> >>> >>> >>>> On Oct 18, 2026, at 5:52 PM, Jan Høydahl <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> +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 >>>>> <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 >>>>> <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] >>>> <mailto:[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> <mailto:[email protected]> >>> >>> Disclaimer >>> >>> The information contained in this communication from the sender is >>> confidential. It is intended solely for use by the recipient and others >>> authorized to receive it. If you are not the recipient, you are hereby >>> notified that any disclosure, copying, distribution or taking action in >>> relation of the contents of this information is strictly prohibited and may >>> be unlawful. >>> >>> This email has been scanned for viruses and malware, and may have been >>> automatically archived by Mimecast, a leader in email security and cyber >>> resilience. Mimecast integrates email defenses with brand protection, >>> security awareness training, web security, compliance and other essential >>> capabilities. Mimecast helps protect large and small organizations from >>> malicious activity, human error and technology failure; and to lead the >>> movement toward building a more resilient world. To find out more, visit >>> our website. >> >> > > Thats funny! We have: > All News - https://solr.apache.org/posts.html > Blog - https://solr.apache.org/blog.html > Annoucements - https://solr.apache.org/news.html > Security News - https://solr.apache.org/security-news.html > > We should at least fix our names: > All News - https://solr.apache.org/news.html > Blog - https://solr.apache.org/blog.html > Annoucements - https://solr.apache.org/announcements.html > Security News - https://solr.apache.org/security-news.html > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
