Note: This discussion was imported from Loomio. Click here to view the original discussion.
Proposal: Adopt a versioning scheme and release cycle.
One thing that would immensely help developers and podmins alike would to be adopt a time-based release cycle. Ubuntu, for example, does a release every six months, and while they have some larger overreaching goals, they only really have to worry about the immediate six-month roadmap for improving the platform.
Similarly, moving to a versioning scheme beyond calling it “Alpha” or “Beta” might be a better indicator of progress on what’s getting done. It would encourage podmins to pull from stable releases rather than just GitHub upstream,
Outcome: N/A
Votes:
- Yes: 2
- Abstain: 0
- No: 0
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
Definitely. I think between getting a stable/unstable branch and adopting a release cycle, we could also make packaging for distorts much easier.
They all just kind of seem to fit together, and a short release cycle can help us better define short-term goals for the platform.
I’m not sure if we really should implement time restrictions, just use regular http://semver.org/ and bump version numbers if needed.
@Jonne: Thanks for the SemVer link, that’s extremely interesting. I think for the sake of packaging and creating dependencies, semantic versioning is a good idea.
My thought on time restrictions: I think part of the problem is that because we haven’t had any sort of time restriction at all, it’s resulted in a wide-overreaching, somewhat vague roadmap, and the constant status of being “Alpha”. I think that by adopting, say, a six-month release cycle (or whatever increments necessary), we could make short-term roadmaps for features, fixes, and improvements, planning accordingly for the chunk of time we give ourselves to hit release. If we have six months to get to a release, then we plan features that can be accomplished and made release-worthy within that span of time.
Granted, roadmap items would probably be smaller, but they’d also be things that we could realistically get done for a given amount of time. Furthermore, if you look at a lot of user-oriented FOSS projects (Gnome, KDE, Unity, Firefox, LibreOffice), many of these types of projects have a time-based release cycle. I believe having that encourages developers to get more done together, and can aid the collaborative process.
Partially related, we could also tag stable releases in our GitHub repo when we approach release time, pointing out to podmins, developers, and enthusiasts that the release is considered stable, or at the very least, having a green build and being stable enough to run a production environment.
We can’t compare to the big FOSS projects. Yet. For Diaspora I still see the possibility that no feature/change justifying a major or minor release is done in that time. On the other hand it might be done shortly after the timed release and then we can’t easily do API breaking changes because podmins might want to deploy this new feature and others want to wait for the next release.
That said I still vote for just doing SemVer, defining our “API” to not only being a potential client API and our federation protocol but also our frontend. Massive changes there should justify at least a new minor release too.
Proposal: Adopt semantic versioning with no time constraints
See http://semver.org/.
With the following changes:
In our case API is defined as:
- Our frontend (major changes -> major version, minor changes -> minor version, you’ll get the idea).
- The federation protocol.
- The client API (not existent yet)
Big internal and structural changes that do not influence the users of all sort (users, client developers, pods), except perhaps for performance, still only justify a minor version.
The version is prefixed with another number which will be increased at community decision instead of a major release. This is to avoid a false sense of rapid development and increasing stability while still maintaining a meaning in the version number changes from the start.
The first version to release will be 0.0.1
Outcome: N/A
Votes:
- Yes: 10
- Abstain: 0
- No: 0
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
I created a new proposal since only two people (had time to) vote on the old one.
I’d really like to see some sort of time-related release cycles. we don’t have to enforce it strictly (if something justifies a release, we should just go with it) and it doesn’t have to be all that precise (e.g a base-cycle of 6-8 weeks, with a buffer of ±2 weeks or whatever would be enough).
But I don’t really like the ‘no deadlines’ structure … it’s hard for me to get work done without a goal 
Can’t “Oh yeah, if I finish that I can release a new version!” be a goal? 
I don’t know about you, but as a student most of my motivation comes from approaching deadlines.
Okay I can see the motivational aspect but that’s the only benefit I see, the downsides don’t out weight that IMO: We would need to decide what to include, estimate if it can be done that time frame (impossible in a project where everybody can join and leave anytime) and lots and lots of bad karma for missing to include stuff while having it announced/stated or postponing a release yet again and again. Remember podmins certainly will plan downtimes for announced releases, that really gives bad karma if we miss it 
Ok I see your point, and I think the downsides outweigh my personal motivation issue
RELEASE(or whatever we could call it).MAJOR.MINOR.PATCH actually according to my proposal.
I think we should just try it with Githubs milestone feature instead of a roadmap.
Seems simple enough; to be fair we haven’t really used it all that much before, but seeing as it’s already there anyway…
Oh, just one thing I forgot in the proposal, but I think we all agree about: A changelog should be included into the repository.
Yep, that’s why I did another proposal just now, so we can init the branching model and release a 0.0.1.0 the first time we got something stable in the develop branch.
SemVer scheme +1 of course.
Timing: What about a time raster. IF there is a new release, release it at beginning of the month. (quarterly is to much I guess).
You have the idea of the two advantages - dependecies + admins ? I could elaborate.
just btw for the ruby gems releases this would be very useful (as guideline!)
Hm, pushing non hotfix releases on something like every second sunday could be an option to thing about. I’ve to think about it a bit more.