Define distribution and release process

[extrapixel]

At the moment, the txt+zip are added to the repository in the "distribution" folder and served via the "raw" link of GitHub:

• https://github.com/extrapixel/gif-animation/raw/3.0/distribution/gifAnimation.txt
• https://github.com/extrapixel/gif-animation/raw/3.0/distribution/gifAnimation.zip

In #13 @jeremydouglass suggested to instead use releases and a 'latest' url:

• https://github.com/extrapixel/gif-animation/releases/latest/download/gifAnimation.txt
• https://github.com/extrapixel/gif-animation/releases/latest/download/gifAnimation.zip

...which is useful, because if is later a 3.1 release or 3.2 release et cetera, that new release and its attachments will automatically become the new "latest" urls on github, and then those urls don't need to be resubmitted to contributions manager and go through a potentially multi-day update and sync process.

lastly there is GH pages ( https://extrapixel.github.io/gif-animation/ ) generated from the gh-pages branch. I think @hamoid at one point suggested to use GH pages as a distribution mechanism.

[jeremydouglass]

I am a big fan of the release format that I recommended, obviously -- I scrape hundreds of projects for archiving, and it seems more robust to me -- but defining any of these three processes is better than not. My personal votes would be for:

1. latest release url
2. raw links
3. GH pages

in that order.

Raw links are good, they just have two downsides compared to releases:

1. To distribute with a raw link you have to check your full release into git version control. With a small library and few releases that isn't too terrible, but for many projects its a non-starter: your whole repo balloons with undiffed binary zip data. Avoiding raw links also follows the rule of thumb "don't put generated files in version control." Some are already there in this repo, but that could change going forward.
2. A raw link is version specific, so you need to update the Processing Contributions library every time you make a release, and the update may take hours or days. With latest release links, the new release is instantly available in Processing PDE.

GH pages or any other website don't have either of these problems -- it doesn't require checking every zip into version control, and you can have a general url that always points to the latest version (like a latest release). Still, it lacks something important that both latest releases and raw links have -- an explicit connection to a version number and a preserved version history. More frustrating things happen with ad-hoc download links on websites when 1) the git gets updated, but the files aren't replaced with the correct corresponding build, or 2) the files do get updated, but the old release files are overwritten and lost, et cetera.