Add "change log" to update card

[simurai]

When updating packages, it would be nice to know what changed in the new version. Here a possible mockup that is based on the #277 branch:

[lee-dohm]

Related to #281 also. I think that if/when this change gets added, #281 should be closed also.

[mnquintana]

:+1: I really like this mockup! Part of me wants the ...more link to be a little more prominent though, or maybe have there be a second link to the release notes that is an icon (the squirrel icon?) in the upper right-hand corner maybe.

[Stanzilla]

Looks very good, and I agree that the "more" links should stand out a little more.

[segphault]

:+1: Very nice. I'd really like to see something like this implemented.

[braver]

I was just thinking of this: there is no method of communicating important changes to package users. Something like this would definitely help. :+1:

[abe33]

:+1: And like @mnquintana I think the ...more link could be changed a bit, maybe wrapped to its own line below the excerpt.

[Stanzilla]

Also maybe hide the changelog behind a button/link you have to press first, could take a lot of space when there are more updates with longer changelogs.

[mnquintana]

@Stanzilla I don't think that would be necessary because the changelog would be truncated in the update cards (truncated to 3 lines here)

[Stanzilla]

Oh indeed, that makes sense.

[thedaniel]

I'd rather do something this than truncate the changelog, as long as it doesn't break the columnar layout:

[davidspiess]

The mockup looks great! Hopefully this gets implemented :)

[zacharytamas]

I'd like to provide this to users of my packages as well.

[piohhmy]

This would be great!

[TrevorJTClarke]

+1! This would be awesome!

[zenopopovici]

I was just about to open an issue regarding this. It's really important to see what's changed.

[jerone]

:+1:

[steelbrain]

Here's my :+1: on that

[eboracus]

This would be fantastic(!) and I agree that looks like a really good implementation, excellent use of space and very little extra bloat to the view. :sunglasses: I think delivering at least some of the info in a zero click manner like that then clicking the 'more' (expanding the package card?) would be preferable to having to click first before seeing anything.

As a bonus that kind of up front display may induce some of those packages that don't currently employ changelogs to do so. :)

[benogle]

Would this be automated or rely on markdown in the body of the release?

[mnquintana]

I'm thinking we should have a series of fallbacks - first check for release notes via GitHub Releases (which would be the easiest, since we wouldn't have to parse anything), then check for a CHANGELOG.md, then a CHANGELOG.txt or just CHANGELOG. For the files, we could either make some attempt to parse them and only display changes for that version (of course, this relies on the changelogs being well-formed and using headers semantically), or just don't bother and display a truncated version of the entire file.

[50Wliu]

A last-ditch fallback could be to just list the raw commit messages.

[simurai]

Hmm.. I'd rather not show anything, than adding potentially too much noise. As a convention it could be this (if that's possible):

1. Parse CHANGELOG.md.
2. Look for the version that the update is for.
3. Show all text till the currently installed version.

As an example with linter. Let's say I'm still using 1.7.2. The latest update would be for 1.8.1. So I would see all this text:

## 1.8.1

* Workaround an atom bug where moving an editor between panes would throw an error
* Allow panel resize to persist
* Add option to always have the panel to fill the minimum space
* Fix issue where external scope errors would cause panel to continue displaying

## 1.8.0

* Improve rendering of multiline messages to align with recent single line changes
* Enable clicking on multiline messages to view next lines
* Add default styles for `Info` type
* Aligned bottom panel buttons
* Made the text in the bottom panel selectable
* Linter bottom panel is now resizable (Drag the height down to 0 to reset your changes)
* Add a new `class` attribute for providers (when class is provided, no class is automatically added).
* Fix linter gutter dot alignment across themes and zoom level.

No formatting, just plain text. Truncated after 3-4 lines.

So, this means if a CHANGELOG.md doesn't contain any versions, it wouldn't show anything. I think that's fine. It's more about giving an option to packages that want to tell users what's new.

[simurai]

first check for release notes via GitHub Releases (which would be the easiest, since we wouldn't have to parse anything)

That would be nice too. Not sure if there should be a push to use either GitHub's release notes or CHANGELOG.md so it would be more consistent.

[thedaniel]

I think we should choose a single blessed source and promote it, not try to handle every case. GitHub Releases is appealing--we could even revive the "publish to atom.io via Release hook" feature. I'm not sure how many people use Releases as heavily as we do, or even want to though.

Parsing the changelog is nice because it's a file in the repo, but Releases are tied to tags and there's no chance of people messing up the syntax and having changelogs we can't figure out how to parse.

[lee-dohm]

We already support CHANGELOG.md even though it is just a link on the package's Settings View page:

So it seems a bit lame to have package authors go back and transcribe all of that information into Releases. If we are going to go the CHANGELOG.md route, we should assume it is Markdown and just convert it and display it. We don't have to mandate a format or anything, just show some HTML and let the package author handle how they want to format their CHANGELOG.

On the flip side, I like Releases and think it would be easier to support in the long run. So maybe it is a bit of short-term pain for a better solution in the long run.

[danielbrodin]

Using apm publish is really convenient, but is there a way to add a description to the tag through it, or would using GitHub Releases mean we would have to manually do a release, or do apm publish then go to GitHub and edit the release description? Haven't used GitHub Releases except for the once created through apm publish, so just asking.

Parsing the CHANGELOG.md could probably be a bit tough since there are so many different formattings, and you would probably only want to show what have changed since you last did an update/install. If the data should be in a file in the repo instead of GitHub Releases maybe a CHANGELOG.json or something would be better?

[zenopopovici]

Couldn't we support both? If one is empty then show the other? This way we don't have to change anybody's work style, and we wouldn't make a decision that's for the developer to make. I don't think it would complicate things too much. Just a thought ...

[thedaniel]

In my experience, in general, it's best to start with one workflow and expand from there in the future rather than trying to support multiple workflows from the start.

[thomasjo]

I think we should choose a single blessed source and promote it

What about Keep a Changelog:question:

[laughedelic]

+1 for the changes list preview on update and for the changelog button next to update button