Back on the topic of releases. There was some discussion on Github here
Seems like the concensus is that Attnam/master is the working space, NOT the "stable" version. Stable versions will instead be released as tags.
I can fork Attnam/master into capristo/master and then make my own changes. After I have tested my changes, I submit a pull request to Attnam/master which is merged in so that everybody else can test.
If I have a larger feature that will take a long time to complete, I can branch my own fork into capristo/FireSystem. Then when I am comfortable with this feature being complete, I should first merge
into capristo/master, and then submit a pull request as usual to Attnam/master.
Then to release specific versions, we should use git tagging because that is basically what it was built for and what Github supports out of the box. For example, after my capristo/FireSystem branch has been merged in, we tag this as version 0.51. All commits up to this point are now released as version 0.51 and can be downloaded as a zip. Then if we fix a few bugs related to the fire system, we can release this as 0.51.1. The next batch of bugs is tagged 0.51.2 and so on. Then when we add the next big feature, call it 0.52.
We should stick to semantic versioning
as much as possible:
0 - major release
51 - minor release, increment when adding new features
2 - patch, increment when releasing bug fixes which don't add new functionality
That was designed for APIs. I am ok with using a letter to denote the patch instead, e g. 0.51a, 0.51b