Prepare 1.1.0

[jrappen]

• updated package structure to resemble a more modular approach
• open CHANGELOG and README via mdpopups
• add ability to open link to project's issues page on Github
• added ISSUE_TEMPLATE for Github

[jrappen]

@deathaxe Although you have a .travis.yml file, it seems you haven't enabled Travis for this repo, yet. Check your profile page on Travis CI. You can also require Travis CI builds to pass for merge requests, see the settings page of your repo.

[jrappen]

@deathaxe Closing this PR due to lack of feedback. Feel free to comment and / or re-open and merge.

[deathaxe]

Sorry, I didn't simply see this PR. Was too busy hacking GitGutter :-)

You are very welcome to suggest any kind of improvements to this package.

Unfortunatelly you deleted your repo :-/ So I can't reopen or pull for review.

[jrappen]

@deathaxe

• read http://stackoverflow.com/questions/7827002
  • read https://git-scm.com/docs/git-apply
  • read https://git-scm.com/docs/git-am
• cd ... into your local repo
• assuming that it is up to date with the master here
  • continue as explained on stackoverflow by replacing the pull request patch link there with https://github.com/deathaxe/sublime-skins/compare/master...68b162b.patch (also read the comments to the answer)

[jrappen]

@deathaxe If you need help, give a shout.

[deathaxe]

Got it. Was looking for such an explanation yesterday quickly, but did not find. I recently saw where to download the commit from. Thank's for the tip.

Some remarks and questions to your changes:

1. I basically like the idea of structuring packages. Unfortunately there is no "standard" or best practice out there. I avoided sub directories due to little package size and most smaller packages not doing so, too. But basically it is a good idea to have some structure.
2. Having one directory for each kind of *.sublime-... file is a bit too granulated I think. As each folder contains only one (or little number of) file(s), it does not make much sense to me. If putting Sublime files into subdirectories, I would prefer one .sublime folder for all as FMCommander.
3. I basically like the idea of using phantom texts to display the readme and change log.

• But I think it was a better idea to use this technique to improve ReadmePlease package, which I use to open README files of all installed plugins.
• Changelog is basically a good thing, but this is the job of package control's message mechanism and if wanted maybe linked part of the README.
• Did you use a script to generate the changelog? Otherwise I find it not so handy. You have to manage commit messages, tag messages, maybe package control messages, and now changlog.md Sorry, but this is to much compared to the little effort to implement the functionality itself.
• I don't think each package should provide its own way to present README and CHANGELOG to the world. It pollutes the command pallet and maybe the menu too much. It could be compared to each theme package to provide its own unique technique to activate the theme. We have Skins to let the user quickly switch between theme and color schemes. So we should have a plugin to provide access to the README of all available plugins (ReadmePlease).

4. I found it a common practice to use "Preferences: Settings" in the command pallet to present the settings command. This is what I think all packages should follow. All other commands should start with the package name as suggested.
5. About Markdown in general. Even though line breaks are not required I would like having the 80 chars line length rule applied. This ensures the text looks good in normal text editors even if they don't support auto wrapping. See Refactor README jisaacks/GitGutter#369 and http://daringfireball.net/projects/markdown/syntax

[jrappen]

1. There is no standard, as you say. Compare Bundle snippets in a "Snippets" subdirectory? sublimehq/Packages#8 and Standard Package Structure sublimehq/Packages#32.
2. I prefer a modular approach, but whatever works for you. Do be advised though that you cannot put python files in a folder with a leading dot as in .sublime/ as importing wont work.
3. You could use gulp via npm for generating a changelog from commit messages, bumping version numbers, tagging, releasing and pushing etc. etc. You'd have to use a particular style of commit messages, though. Compare angular/angular:CONTRIBUTING.md#Commit_Message_Guidelines on style advice. Compare Material Theme and Boxy Theme for the required setup.
4. Sounds good.
5. Ok.

Take whatever you like from this PR and drop the rest.

[deathaxe]

1. Very interesting threads. I get starting to like that idea and understand your approach. At least using this structure could encourage other devs to follow such rules, too.
2. Agree. Later in the evening was thinking about 'modules' for python files, but your 'lib' matches python's standard library name and might be a better name to use. (Same with some other folders)
3. I don't use node as I don't use/need JavaScript at all. I tried playing with it a bit, but I find the whole JS-stuff bloated memory eating bullshit. I tried a little OPC-UA server exporting one variable requiring 130MB RAM? I still need to struggle with 1,5MB of embedded systems each day so this is something I can't feel familiar with. The only thing I like node for is its really good asynchrounous approach.
4. I am not so familiar with best practices on markdown yet. Still trying to find my way. So I'll be pleased for any good advices.

What do you think about eighter contributing to ReadmePlease or create a new package for it? This would make your cool code work for any package efficiently.