Should we improve our release process?

[Alok Menghrajani]

I don't think we have documented our development process which boils down to:

1. Add new code to master (with all changes visible to the open source community as pull requests and tasks/bugs tracked as issues). These changes are only tested on our local development setup.
2. Cut a release branch, currently numbered 0.7.x
3. Deploy the code on Square's staging environment.
4. If things look good, deploy the code on Square's production environment.

This process is significantly more transparent than alternatives such as internal forks. We however do not have a way to communicate if a release is stable or still undergoing tests. Newly released versions may have bugs or performance regression issues.

I suggest we append a -pre suffix to the release in step 2, adopt an odd/even numbering scheme or some other convention. We can then add a step 5. to create a -stable label (or some other system to communicate that a release is ready for production use).

[Alok Menghrajani]

We can live with the way things are currently setup.