We need a clearer PR/release process

[joelanman]

Currently, we have a version of the kit on master which says it is 4.0.0, but it isn't - it has the new gulp stuff. That's an issue if people download it, and we try to help them with an issue, and the version number is wrong.

Some options:

1. Bump the version number on every PR merged
2. After release, set the version number to something like 4.0.0-dev
3. Merge PRs to a branch other than master

With option 1, would each version number be available as a release? That doesnt seem right - it would be very noisy and I wouldnt be confident about telling people all those releases are right to use - as we dont have a proper testing process

[joelanman]

a test suite will definitely help with this #292

[robinwhittleton]

People will generally just download the latest release. The Heroku docs link through to the zip bundle of the latest release, and the non-technical installation instructions point to that too. The only people who will get a non-release copy of the code are people technically competent enough to clone a repository, and they should understand then that they might be using a prerelease version.

Either way, we should be releasing more often. The more you release, the less changes there are to review when the release happens, and the less likely it is that something will break on the user’s machine. Bumping the version number on every PR feels a little excessive, but 4 months between releases is definitely too long.

[joelanman]

@robinwhittleton this is not hypothetical, but a real issue we've seen happen - with non technical people downloading master from github. However with the new site, maybe this will happen less often.

It'd be great to release more - but as with every other issue on the kit, we don't have any people assigned to it at all. I agree 4 months is too long, but its better than nothing :)

[vickytnz]

The phrase 'technical' is one to be careful about - I'm technical enough to download from github etc but had never realised about releases etc until reading the blog post about archiving versions of the prototype. (I'd hazard a guess that people such as me from an IXD background are more old-skool coders who are decent on git but less so on pull request etiquette etc).

And I'm nowhere near technical enough to deal with bleeding edge problems with gulp/node/nunjucks filters etc.

Generally I'd expect master to be the latest stable version! It's frightening if you upgrade your prototype and things break (I remember there being a problem with filters etc one time I did this that made everything come up as an error).

[edwardhorsford]

@robinwhittleton anecdotally I've seen loads of people who have the latest from master rather than a release. It's not just technical people. When you go to the main repo page, the 'clone or download' link is just too tempting.

Like Joe I think this will improve with the new kit docs, but we'll still get loads of people who download directly from master rather than a release.

[andymantell]

If you want to keep master stable, you could have a develop branch which would be your unstable work in progress (feature branches would be merged into develop, never master). Then make a PR from develop into master when you want to release a bunch of stuff. Docs are great, but let's face it, people don't always read things. A stable master branch seems like a good fit for this repo to me.

[edwardhorsford]

@andymantell yeah, I think that may be the best route for this repo.

[joelanman]

Closing this for now:

• we have a kit site that always clearly links to the latest release
• we have tests that help us keep master more stable, and do more regular releases