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!