Update: New versioning system
Jon Lemmon PublicSeen by 18Implement semantic versioning system for Loomio
proposal by Jon Lemmon Closed Wed 26 Sep 2012 12:01AM
I propose we implement basic semantic-like versioning for the Loomio codebase.
The currently deployed version of Loomio will become 0.0.x.
- We'll increment the tiny number (0.0.x) when new bug-fixes are implemented.
- We'll increment the minor number (0.x.0) when there are new feature additions that change the database or models in a significant way.
- We'll increment the major number (x.0.0) at our own discretion when there are significant changes to Loomio that we think warrant a new version number.
The master branch will still remain the place where new features are developed.
I won't define things much more than this, because I think doing so would probably be more harmful than helpful. So I propose we start with this system and then iterate based on our future needs.
Results
| Results | Option | Votes | % of votes cast | % of eligible voters | |
|---|---|---|---|---|---|
| Agree | 4 | 100 | 1 |    | |
| Abstain | 0 | 0 | 0 | ||
| Disagree | 0 | 0 | 0 | ||
| Block | 0 | 0 | 0 | ||
| Not voted | 271 | 99 |               |
I actually think this system might be a bit of overkill, but I think we should give it a go and see what happens.
sounds like a good way forward to me
Sean makes a really good point about version numbers and perception. Seems like a good idea to me
Go for it. It's something we're using with Diaspora now, and honestly, I think it's a good system. As a project, it's good practice to not just use release labels ("Alpha", "Beta", "Release Candidate"), because as a startup, it's difficult to illustrate how much work is actually being done.
When a service says it's in Alpha or Beta, and it's been like that for a while, it creates the unfortunate perception that the project isn't moving, even if it really is. Diaspora went through several major rewrites during the Alpha stage, with a lot of features added and re-worked over time. As we move over to SemVer, we'll be at a 0.0.1 initial release. Had we implemented it from the very beginning, we probably would be v 3.6.1 or something close to that.
However, because we didn't use a formal versioning system (as is popular with social startups that have amassed developers and venture capital), a lot of users left over the complaints of us not getting to Beta fast enough, even though Beta had no formal definition at the time for that user.
Perception is a funny thing, but it makes a big difference in the long run, and proper versioning can lend itself to be useful in the case of showing actual progress.
Hey Loomio Coders,
It's gotten to the point where I think we need a basic versioning system for the Loomio codebase.
The reason I say this is because the current code on master is significantly ahead of the code on our production server. So we have a need to have an active branch of development (master) and at the same time be able to push bug fixes to our stable production branch. The other reason is because I think breaking things up into versions will help drive development and make it easier to coordinate upcoming changes
So that being said, I've taken the liberty to implement a basic versioning system for the Loomio codebase.
The currently deployed version of Loomio is 0.0.x. If you want to commit bug-fixes to the current version on production, this branch is the place to do it. This branch will always be a stable repo that we can direct people to if they want to grab the latest version of Loomio to deploy on their own server.
The master branch will still remain the place where new features are developed. So if you have new features to contribute, master is still the best place to commit them to.
I'm not convinced that this is the best way for us to be doing things, but I thought it'd be a good start. If anyone has ideas of better ways for us to handle versioning at the moment, please say so!
I'll put up a proposal now just to make sure everyone is cool with this.