I do not like the "read more" UI

[florianschanda]

At the very least, the release notes should fully expand the latest release.

Right now, with the new UI it just hides everything which is really not helpful.

[ashishbeck]

I second that. "Read more" should load the remaining text instead of opening a different page

[Jolg42]

+1 here, this makes it hard to check multiple releases easily.

[Zwatotem]

Just make sure to load the page anyway, if client-side scripts are disabled.

[MylesBorins]

This is now the behavior, PTAL.

[jbergstroem]

I concur; would also like to see the latest post in full (including the downloads - how do I "get" the release?) and the following releases in a more compact representation. Perhaps use similar logic to how README.md's are reduced when shared across the internet, or allow a divider to separate a summary from the details, which then automatically becomes the summary in a condensed format:

This release mostly focuses on fixing BGP routing alongside some small ui tweaks.

---

Commits
- ...

[MylesBorins]

All downloads have been brought back to the list view. At this time we are not expanded the latest release by default as there is some inconsistency in how we identify / sort the latest release. Once we iron that out we'll likely make the latest release expand by default

[Pacoup]

Also, the page nav doesn't currently remember the scroll position (it's just a load in, like with React or something), so if you click Read more, scroll down, and then navigate back, you're suddenly lower down the previous page than you were.

But really, besides the router code being too basic, this UI dedensification must stop.

1. Click on Read more

2. After scrolling down

3. Hit the back button

[serverwentdown]

I agree too, the "Read more" UI makes it really hard to find a specific release that introduced a feature by scrolling the releases page (like a changelog).

I think Releases is better if it serves as a changelog rather than a summarised changelog. Too much content is hidden under the "Read more" link.

[Gakk]

I completely agree. This is especially painful if you were a few versions behind, and would like to catch up on all changes from e.g. version 1.1 until 1.6. I always read through the release notes of all nuget-packages I am skipping over, hiding this partially behind "read more" makes thing harder.

[michael-yx-wu]

For repositories with frequent releases, it has never been easy to search for specific changes across multiple releases but hiding text content behind a Read more link makes it pretty much impossible. Showing more releases on a single page is not that valuable compared to being able to see the full content of each release.

[porg]

To the UX designers of this new feature:

• Note that release notes are not only consumed one-by-one like a blog is read!
• But they are a log, have a chronology, and often for investigations/compatibility/strategic planning you need to find out what happened when and changed how over time. And do this in an efficient manner. As it is now is totally unusable!

STORY: As a user I want find out when "feature X" was introduced or changed.

• OLD: "Find in page" (CMD-F) for "feature X", jump through the results, and see them in context. Perfect already.
• NEW: Sheer impossible now. Also using your "Search" function for "feature X" yields totally incomprehensible results, where the query term seems to get matched somewhere in a release note, but not in the visible part on top! That's a big no-no in search UX.

Proposal:

1. I'd leave the release notes expanded.
2. Introduce a TOC, sticky-position, collapsible into an TOC-symbol and expandable on click
   On mobile starts collapsed, on larger screens expanded, somewhere on the side.
3. Controls for "Expand/collapse all" release notes.
4. When on the bottom, don't paginate, but rather "load more" (older release notes). Then your local search can traverse further back into history.
5. Clicking a release in the TOC which is yet not loaded, lazy-loads all releases till then. If too many, give a warning "Do you really want to load all 120 release notes till there?" with: [ Load All ] [ Load release + 10 elder ]

• The latter is the primary button. In the release card order it simply leaves a gap, illustrated as "--- "110 more releases" [Load more] --- " like GitHub already does for "3 similar messages" which you also hide in discussions.

[MylesBorins]

We've made significant changes to the list view, please take a look and let us know if you think we can do more.

[Gakk]

A nice workaround that works for me:

• Open releases (all release notes are truncated)
• Click in search box
• Click enter (searching for empty string)
• All releases are now still shown, with complete release notes expanded on all 😀👍

[wrooot]

Switched back to old UI in a second. Having to load another page to download assets. No.

[MylesBorins]

We fixed the regression in which the list view didn't show assets. PTAL

[MylesBorins]

We are having discussions about what we can do to improve the experience regarding the list view and the abridged content.

We are also actively working on improving the search functionality. The number one reason folks have been bringing up that they want to see the full content is because they rely on searching the text of the page manually to find specific content. It feels to me like if we significantly improve the new search functionality and show unabridged content with highlights on the results page we could significantly improve the overall experience of finding specific details about releases which seems to be the primary user journey we are talking about here.

[porg]

Please see my post which contains both critique plus proposal. Please consider it.

[MylesBorins]

@florianschanda search in the browser only searches releases in the current window. Our updated search will query all releases in the history of the project. I do not believe that is a duplication of browser functionality

[porg]

1. The archetypical GitHub persona is someone with a least some tech-affinity. So definitely capable of using the local browser search function.
2. We are all aware that local search only searches within what's currently loaded in the DOM. Hence in proposed to "Load more" (instead of paginate) as a simple means to "widen search scope".
3. The excellent part of simply using local search is that you can both search, jump search results, but inbetween also browse around, freely scan around. A server/client-side search function which beats this is maybe possible, but a high level of innovation required to do it really good.

Please really see my proposal. Also contains idea for collapsible TOC and expand/collape all releases controls.

[ychin]

A pet peeve of mine is when websites get large enough to a point that they start trying to hijack or replace browser native features, like… search. I really don't mind search locally. I understand pagination means I have to load multiple pages, but as a technical person (I would imagine the average user who uses GitHub is at least somewhat technical) I would prefer having some escape hatch to just hit Cmd/Ctrl-F and just find the thing that interests me.

Hiding things that you need to manually expand one-by-one and then replacing them with a non-native search kind of seems like solving an invented problem to me. I don't mind a collapse-all/expand-all button, but making things just a few lines tall break a lot of release notes as you can't even show enough to show the summary.

[wrooot]

Yeah, i wonder what was a user story/case for this new design. Someone complained they are tired of scrolling?

[nlohmann]

For my project, the new releases look really broken:

I could imagine adding some Markdown tag to control where the preview is split.

Furthermore, I don't understand why the latest release should have as much (or as little) space as all other releases. Maybe resizing the size of the latest release could be beneficial.

[MylesBorins]

We are going to make the latest release show the full content.

[ann0see]

I could imagine adding some Markdown tag to control where the preview is split.

Exactly. That would allow developers to break the release notes where they want them to break

[idbrii]

To present a lot at once, it'd be nice to see the same data we see in the current UI, but with everything collapsed inline instead of different pages.

• Heading: same as current
• Description: Show the first two lines of description and add a read more expando so text becomes visible in-line. Prefer to cut at headings or lines instead of character count.
• Assets: Show the assets using the current expando

Even better, when a user expands/contracts one of these two expandos, remember that state. Whenever displaying a release, use the same state as the default so the user doesn't have to repeatedly expand/contract.

[MylesBorins]

Assets are now back in the list view. I'm about to post an update in this discussion with the current plan for improving hidden content

[caseif]

In addition to this, it would be nice to have an "expand all" button or maybe just a user setting under "Appearance" that toggles such a feature. Allowing release text to be expanded inline would definitely be better than opening a different page for each one, but having to do this repeatedly still seems a bit tedious and regressive in comparison to the current UI.

[MylesBorins]

We are exploring a single attribute that could be passed to do exactly this

[MylesBorins]

As a quick update.

We just shipped assets in the list view, which should fix a number of complaints. We are also exploring major changes to how we hide content in the list view and are in the process of doing an engineering spike to determine the exact implementation but are exploring the following

• Showing the full notes for the latest release
• Showing the full notes for all releases in search results
• Highlighting search terms in search results
• An attribute to show full releases rather than abridge
• Making "Read More" show the full release notes rather than forward to another page

For the last two points we need to do some analysis of performance and determine what is the best path forward

[porg]

Definitely a better direction already. Thanks for hearing us.

[MylesBorins]

Another quick update. We've just shipped everything I mentioned above aside from highlighting search results. please take a look!

[Die4Ever]

"An attribute to show full releases rather than abridge"

how do I do this?

[jgustie]

While I do like the overall look and feel of the new releases page, I find the abridged content for the release notes problematic. I feel that it is ultimately the responsibility of the release publisher to determine if abridged release note content is appropriate for their project, not the viewer. Likewise, I have always assumed the contract for release notes was "here is a block of Markdown, and it will be displayed—in full—for both list and detail views"; i.e. it is the release publisher who makes those notes short or long enough to be relevant for a given project.

One alternative might be to have a "summary" field associated with releases that can be shown in the list view so release publishers can still control exactly how release notes are displayed. Another admittedly less friendly alternative could be to provide collapsible content sections via markup in the notes themselves.

In my opinion, giving up this much control over the release presentation makes the feature less desirable overall: personally I see myself more likely to switch to a manually maintained changelog and hide the releases from the project home page.

[jgustie]

Just more thinking out loud as I process this: I often place security notices or breaking changes for a release near the bottom of the release notes because it is closer to the asset links where the user ultimately clicks to download release content. With non-latest releases collapsed by default, these potentially important notices quickly get lost as patch releases roll out.

[porg]

@jgustie

• "collapsible content sections" aka "spoiler blocks" are already possible within the scope of Github flavored markdown.

@MylesBorins

• I made a request at the user forums to please add this value-able info to the documentation. No reaction so far.
• Now that I have your attention as someone from the design team, could you please tell your editorial team to take care of this information marvel?

[MylesBorins]

@jgustie at this time we are not looking to extend or complicate GitHub flavored markdown or to have special markdown features specifically for releases. We explored this space but opted to not pursue it as things get quite complicated quite quickly. We want to have a consistent experience across GitHub and across repos and we use the same truncation tool across the platform. That doesn't mean we can't improve how we do truncation though!

@porg the reason it isn't documented is because it isn't GitHub flavored markdown... it is simply inline HTML. There isn't GitHub flavored markdown specifically for details. We don't document HTML features.

[porg]

@MylesBorins Thanks for explaining the reason/policy behind. Closed my support community inquiry accordingly.

[MylesBorins]

Hey all. We've shipped 3 major updates over the last 24 hours.

1. Clicking read more now expands content in place
2. Significantly improved pagination
3. Significantly improved search including special search syntax

PTAL

We'll have more fixes coming next week including expanding search results by default.

---

Search syntax for searching releases in a repository

You can provide text in your search query which will be matched against the title, body, and tag of the repository's releases. You can also combine the following qualifiers to target specific releases.

Qualifier	Example
draft:true	draft:true will only match draft releases.
draft:false	draft:false will only match published releases.
tag:TAG	tag:v1 matches a release with the v1 tag and any minor or patch versions within v1, such as v1.0, v1.2, and v1.2.5.
created:DATE	created:2021 will match releases created from 2021. You can also provide date ranges. For more information, see "Understanding the search syntax."