fix gh-page in master branch / enhance auto-versioning

[amacado]

While implementing this new feature I noticed that the migration from gh-pages branch to master-branch does not work yet. When we want to use the /docs/ directory as entry for the GitHub page we will not have access to files stored below /docs. Therefore it's required to copy our resulting build files (as well as the svg icons) to the /docs/dist directory. This extra step allows us to reference them in the Github Page. I fixed this in f97406d (Implementing method for copying the resulting build files (and source svg's) to /docs/dist folder allowing them to be used in GitHub page (see #394))

About the new feature:
As described in #395 we can use the github api to determine the latest release tag. This we the header (and CDN links) will auto-update itself once a new release is beeing made. This behaviour is nice, but can also cause some potential problems when we decide to change our release strategy. For now it's a simple solution and it should work as a first version. I also implemented a fallback to 'master' branch when the determination failes for any reason.

[amacado]

I suggest to look at the commits independently, so you are able to handle the "500+ files" (reason for this is mentioned in the description)

[Thomas-Boi]

Hey @amacado,

I just want to clarify something. What is the current publishing source for our website? The site seems functional at the moment, is there anything that I'm missing?

Also, it is true that choosing the docs/ folder will limit all publishing resource from there downwards. However, I think we can bypass this by using the URL.

Currently, this is how we get the icons and devicon.json:

  var baseUrl = window.location.origin; // should return "https://devicon.dev/"

  // Get devicon.json 
  $http.get(baseUrl + '/devicon.json').success(function(data) {
    // do stuff
  }

This should break since we don't have any devicon.json in docs/ and GitHub Pages is limited to this folder. However, what if we do this?

  var baseUrl = "https://raw.githubusercontent.com/devicons/devicon/master"  // base path for the raw files

  // Get devicon.json 
  $http.get(baseUrl + '/devicon.json').success(function(data) {
    // do stuff
  }

I changed the baseUrl so that it would point to the actual json file when we append /devicon.json. This can also be used for the icons as well, like this:

Base: https://raw.githubusercontent.com/devicons/devicon/master (doesn't work by itself)
devicon.json: https://raw.githubusercontent.com/devicons/devicon/master/devicon.json
Android svg: https://raw.githubusercontent.com/devicons/devicon/master/icons/android/android-original.svg
Babel svg: https://raw.githubusercontent.com/devicons/devicon/master/icons/babel/babel-plain.svg

The link should work since it's a normal HTTP call so it's not limited by the publishing source. It would also point to the most recent commit of master so we never have to update it. This would also eliminate the need to copy the svgs into /docs for every release and reduce the size of our repo.

What do you think of this approach?

As for your solution for #395, I like it. It should work for a while since I don't think we need to change our release plan anytime soon.

[amacado]

I just want to clarify something. What is the current publishing source for our website? The site seems functional at the moment, is there anything that I'm missing?

Currently our site is served by the branch gh-pages. Since we want to change and migrate to master branch we decided to serve it from docs folder.

Also, it is true that choosing the docs/ folder will limit all publishing resource from there downwards. However, I think we can bypass this by using the URL.
Base: https://raw.githubusercontent.com/devicons/devicon/master (doesn't work by itself)
devicon.json: https://raw.githubusercontent.com/devicons/devicon/master/devicon.json
Android svg: https://raw.githubusercontent.com/devicons/devicon/master/icons/android/android-original.svg
Babel svg: https://raw.githubusercontent.com/devicons/devicon/master/icons/babel/babel-plain.svg
What do you think of this approach?

I came up with this solution as well, tried it and it works as expected. At first I though this would be a great idea, since it does not duplicate a bunch of files, always up to date,... But on the other hand .. seriously? I forget about the reason why I changed it (I know I had some point but i can't remember it anymore). Maybe it was just late at night and my brain got afk for a moment. I will recheck it and see the result.

[amacado]

@Thomas-Boi I updated all links for fetching the resources via raw.githubusercontent and it seems to work for now. So this is ready for review and merge.

Anyway: While doing this I was thinking of refactoring the page itself since it's still using the old AngularJS version which is already outdated. I'm more into VueJS these days so I might propose a updated version of the page in the upcoming days.

[Thomas-Boi]

@amacado That sounds good to me. I'm learning Vue right now and it is more flexible than Angular for me so I'm happy with that.

I'll approve your change and accept your PR.