Semantic Versioning and Releases

[catarak]

Nature of issue?

• New feature request

New feature details:

I was thinking about how rad the p5.js 1.0 release is, and thinking about how to in general improve stability and testing on the web editor, and #1398 got me thinking that there really should be a staging deployment....

So anyway. I was thinking that maybe the web editor should adopt a release system. It would be especially useful for big features (for example, like collections), to not have to be on a separate branch, getting more and more out of sync with master. This becomes a big issue when there are multiple projects that are fairly large. This is what I'm thinking:

• deploy (or maybe release? naming is hard) branch is what's on production at editor.p5js.org
• master is where active development is done. This is where pull requests are merged. This is what is deployed to staging.editor.p5js.org (which is maybe password protected? maybe only has certain authorized users?)

It gets complicated when thinking about how to bring stuff over from master to release. Making lists of all PRs that should be in a release? Cherry picking? This is new territory for me so I'm open for ideas to make this as easy as possible. I don't even really know how p5.js does releases so I'm going to start there.

Releases would also be nice for hosting your own instance of the web editor (#1156). The docker image could be tagged with the release!

[andrewn]

Absolutely yes for a staging server that's automatically deployed! This'd be very useful for all the reason's you've mentioned.

I'd vote for the production branch to be called release.
And the active development branch to be called develop, avoiding using the wordmaster.

One issue with long-running features on master is how to then make smaller releases (bug-fixes, small new features). If they're urgent enough then we could cherry-pick them directly onto production but I think this will get messy.

I'm a big fan of always having master in a deployable state. The staging site should never be intentionally broken or un-releasable. To achieve that, anything that's not ready should be behind a feature toggle.

We've had some success using them on the project already, using environment variables to turn features on/off. We could also have them in the client web app itself, allowing us to enable/disable features in the browser.

A "release" should always just be merge from master to release. That way, we avoid the unintended consequences and interactions of cherry-picking.

[catarak]

Thank you for your input! It's helpful to know I'm approaching this the right way. I don't want to add unnecessary complication to releasing code but it's feeling like this project really needs it. To summarize:

• develop is the active development branch. All pull requests (features and bug fixes) are merged to this branch. I agree that removing master/slave terminology is important, and I appreciate the reminder that in this case I have that power.
• release is what is on editor.p5js.org. This will use semantic versioning for new releases. I think this should start at 1.0.0 (esp. given the p5.js 1.0 release).
• For big, longer term features, these should be merged in smaller pieces to develop. For things that shouldn't be public yet, they should be hidden via a feature toggle (which could be environment variables, an alternate URL, or something else).
• Cherry picking should be avoided unless absolutely necessary, like for an urgent bug fix in a case where develop is not stable. But probably this shouldn't happen?

Okay cool, I'm excited about this! I think this is going to be invaluable for GSoC, and therefore want to try to get this done within the next three weeks.