Create Releases of Stash about stash

[StashAppDev]

The way it's set up right now a new release gets posted automatically ~15 minutes after a successful push to the master branch. There is only one release listed, but it gets overwritten. I'm going to keep it this way until I feel it's in good enough shape to start tagging version numbers.

There isn't really an indication that there is a new version on the releases page by doing it this way though. I guess you could keep an eye on when master was last updated. Perhaps I can add a release notification on Slack.

[chimerasoup]

That makes sense. After things have settled down, would you be willing to do development in a different branch, then create releases when you merge the development branch(es) back to master?

[StashAppDev]

That's the plan.

[WithoutPants]

@StashAppDev @Leopere can we revisit this? Would be nice to separate development releases from a stable release, even if it's just a 0.x release.

[Leopere]

Ideally, we should be merging things to "production" when "ready" however we've not really been doing versioning. To avoid maintaining every version we've ever published we should definitely make sure that whenever we add our #197 feature we have it check what the latest release is and mention to the end-user that they must upgrade to the latest version before they can submit a git issue as their issue may be related to a bugfix since their version was downloaded.

It was mentioned a bit ago that we should start dialing in what our scope of a 1.0 version would be including refining our versioning system using something like to SemVer 2.0.0. Once we reach 1.0 "stable" we should have a production branching system worked out where only tested stuff should be pushed to Production.

All of this said so far we should absolutely aim for only commits with working tested versions of the app where theoretically all commits that can be pulled can be run if compiled at home once we hit 1.0.

This should be included in a CONTRIBUTING.md #211 gets the ball rolling if you want this please contribute to this PR.

[WithoutPants]

I'd like to keep discussion here, and I'll submit specific stuff into the PR.

I think as it is, we should release the current master branch as version 0.1. Per the SemVer spec, I don't think we should consider the current API as stable - even though no doubt people are using it in a production environment. At the very least, the API needs to be validated and documented, since we don't want to have a sub-optimal interface dogging the API because we were unable to properly deprecate it.

Now that develop is the default branch, my suggestion is to have travis build dev releases from the develop branch. We could consider dropping the auto tag and release from the master branch to do releases via manual tagging. That way we could create change-logs, release candidates and so on.

Having stash tell the user when a new version is released (including dev releases if they are on that stream) would be valuable in my opinion. It's on my radar to add, but I'd like to lock down what we are actually doing with releases first.

[WithoutPants]

I think this is resolved. We've got a basic release approach implemented.