Default filenames as alternative for 'messages.json'

[FichteFoll]

Many messages.json use the same format, which looks similar to the following: example-messages.json SublimeLinter InsertDate (Except that the last one does not trigger the install.txt for me. Ideas?)

What about using this scheme as a default approach and check whether a file with that path exists when there is no messages.json in the repo? This would reduce the required filecount by one while still maintaining the current structure.

[wbond]

Hmm, so if I install version 1.5.9 and version 1.4.3 was installed before, I would scan through the messages folders and look for what exactly? Would I look for all .txt files and if the name was properly interpreted as a version string, compare it to old and new versions of the package?

That could potentially work.

[FichteFoll]

Yeah, exactly.

If this would be too much of guessing I think you can also include an option in package_control.json (those linked in the channel repo) which then makes Package Control auto-scan for these update messages if there is no explicit JSON file specifying the paths. Though, I doubt this is necessary.

[FichteFoll]

What do you think about supporting a general INSTALL.md|rst|txt and CHANGELOG.md|...? Iirc github also features the changelog thing somewhere but I'm not too sure about that, might also be CONTRIBUTING.md.

Anyway, the changelog feature itself would not "crawl" all release notes and display the relevant ones but instead display the changelog itself and probably the versions that have been updated from and to. I dislike having to split my changelogs for each version in a separate file so I'm always refering to my CHANGELOG.md file with the messages.json, but this would result in PC probably displaying the same file twice or more when skipping versions with an update.

Edit: I don't do that anymore btw because it's a bad experience for users.

[gerardroche]

I like the CHANGELOG.md idea. It's too much to maintain the messages.

• on install
  • if messages exist use those
  • otherwise if a README.md exists then open that
• on upgrade
  • if messages exist use those
  • otherwise if a CHANGELOG.md exists open that with some information inserted into the top of it: "upgraded from version x.x.x to x.x.x"