It’s been a long time now since we released new versions of our software. So it’s about time :-)
- Crazyflie Nano Quadcopter Firmware 2013.11-beta1 (download)
- Bitcraze VM 0.4 (changelog) (direct download) (torrent)
- Crazyflie PC Client 2013.11-beta1 (changelog) (source download, Windows installer download)
- Bitcraze Raspberry Pi SD-image 0.2 (changelog) (direct download) (torrent)
Here are some highlights from the releases:
- Altitude hold support in firmware, PC client and Raspberry Pi SD-card image
- Bitcraze VM upgraded to Saucy Salamander (13.10)
- Lot’s of bugfixes
One of our big topics of discussion at Bitcraze is how to release and when to release software. Our plan has changed over time and this time around we are trying something new. First off the version naming is (as before) constructed using the year and month. New for this release is that we decided to make a beta release before making the real release. If the feedback is good on the beta, we will just rename the release after a week of testing.
When it comes to handing the issues in Bitbucket we have tried an approach were we minimize administration. After every release we create a new milestone named after the last release (i.e 2013.11+). Everything that is supposed to go into the next release is then added to this milestone. When we do a new release all the resolved issues/implemented features that are closed and added to this milestone makes up the change log. Issues that are not resolved are moved to the next milestone.
The discussion we have had for the last week resolves around the release schedule and whether or not do do a pre-release (release candidate). Up until now we have had the goal to do feature-based releases (although there haven’t been that many releases…) but we have now started leaning towards trying period-based releases. We feel that it’s very easy to drag on and not release a new version since we want more and more features and fixes in it. Ideally we would select a few that would go in and then stick to it, but we are having a hard time doing this. Below is a quick outline of the idea we have for the future releases:
The idea is to release a new version of the firmware/client about every two months (8 weeks). First we create a new milestone that we assign issues/features that we think we will be able to fit in (i.e for the next release this would then be 2014.01). After 7 weeks we branch and create a release candidate that the community can download and try. If any major bugs are found they are fixed and then the release is done. Our goal with this is to release more often, even if the releases might contain less things.
So what do you think about doing period-based releases instead? We think that the community should have a say in this, since you are the ones using the releases. So go ahead and vote, we know you want to!
Loading ...
Here’s a comment from Johannes who had problems with captcha so I’m posting it instead:
“I don’t need “a lot of new stuff” for a new release, so period-based seems to be “better” fit my needs. Feature/fix-based could also be interesting if you don’t set your goals too high.
Either way it should not lead to poor quality of the releases. Period-based tends to be that way. Have a look at ownCloud, they are planning releases regardless of a bugs state:
https://github.com/owncloud/core/wiki/ownCloud-6-Features#schedule
If it comes to “we release today, whatever the quality is” I personally don’t want period-based releases.”
Thanks for the feedback!
Hello bitcarze team,
many open source software projects do feature releases AND periodic builds.
You find many high quality, well tested feature release lets say about four times in a year.
In addition stable, working but only automated unit tested nightly builds are provided for download.
Experimental features will become only part of this nightly builds if they are finished (feature branch is merged into your default branch)
You can find similar ideas also in this crazyflie-firmware github fork where already automated builds are available …
Perhaps this fit also the current poll result where the same number of people want a feature and period-based releases.
Bye, Bye
A major problem I see with short release cycles is that old bugs will get fixed and at the same time new features with bugs are introduced so you never have a stable release.
During first stages of software development a short, fixed, release cycle is great but once the product has released a 1.0 version I’d like to see a different release pattern. From version 1.0 keep a stable release branch combined with a separate release of nightly automated builds for the newest features. Major bugs fixed in the nightly builds are back ported and released in the stable release. When the development branch has grown a useful set of new features a new stable release can be created. How often a new stable release will be created is undetermined, it depends on the number of new implemented features.
Hi all,
Thank you for your comments. The poll was kind of inconclusinve to I guess we will have to invent compromise (Good thing that Sweeds are good at compromise, even though I am the non-swedish one in the team :).
@Johannes: The ‘release candidate’ phase is intended as ensuring that the quality is there. The basic idea being that we branch the code for a new version and if a new functionality is found to have too much bug it is removed, or disabled, in this version branch. We still have to provide a clear channel to report bugs, certaily throw the bitbucket bug tracker.
@C. Kielstra: As Crazyflie is intended for developper and makers we are hopping to never reach a 1.0 on this one. This does not mean that we don’t want it to be stable but we do not want it to stall in functionality. I like the idea of having two running branch but we though that might become too much work merging back bugfixes and then merging the complete dev branch. That why we though of making a new stable branch for new version and then merging bugfixes into it until the next version come and a new branch is created.
@Gerd: Nightly/stable build and feature branch could be a good idea. We are looking at how we can make it happen without it being to much of a mess :).
Thanks for the great feedback. Now looking at the very inconclusive poll result we are even more puzzled than before. A mix between timely based and feature based is quite appealing and we are thinking about it. Also we will look a lot more into nightly build and test, this is something that will really ease the QA process. How does that sounds to you?
Best regards