Nightly builds

[borekb]

It would be great if Travis had another step that would build VersionPress and publish it somewhere so that:

• Each build is uniquely identified, which our npm run build script already does. It creates something like versionpress-4.0-beta2-9-gd9a03c79.zip, which means "the closest tag is 4.0-beta2, there have been 9 commits since then and the build was from commit d9a03c79".
• When in a branch / PR, the most recent build would be aliased as https://some-service.com/versionpress-branch-name.zip
• Latest builds from master would be aliased as https://some-service.com/versionpress-master.zip or .../versionpress-nightly.zip.

That's the best setup but whatever gives us versionpress-nightly.zip on some known URL would already be quite useful.

[borekb]

Copying recent discussion from Gitter:

---

Craig Andrews @candrews May 08 21:01
borekb, when are you thinking of making the next 4.0 beta release? I'm finding it very... inefficient... to manually patch my various VP installations with the changes made since the last release :)

Borek Bernard @borekb May 08 22:29
I think that nightly builds would be a good solution to this: #1433
because otherwise, you could argue that we should cut a release after every bugfix merged – there's always someone who would find that useful

Craig Andrews @candrews May 08 22:39
However, releases should be made periodically. For example, if there is only one commit made and a year passes, a release should be made - users and contributors shouldn't have to wait too long for fixes to be released.
I don't know if that period is a week, a month, or a year... but releases should be made sometimes.
Or at least have a roadmap with dates so users know to expect and can plan.

Borek Bernard @borekb May 09 00:13
generally, I think we should:

1. provide an easy way to install the latest / master version
2. tag a release when enough interesting changes accumulate

in practice, most people during this Developer Preview period should just run master – it's as stable as any official release (thanks to CI; we don't really do much more manual testing before cutting a release). regular releases are more about documenting the progress and having points in time that are named.