So I have been thinking recently about how to deal with Toucan development in the future, specifically with regards to when to release new versions. Currently there is quite a long time between releases, which is fine if you aren’t affected by any bugs and are just looking forward to new features, but is a nuisance if you are affected by a bug. In the table below you can see the time between releases of Toucan so far:
Version | Date | Time since previous release |
---|---|---|
1.1 | 2007-08-01 | n/a |
1.2 | 2007-11-21 | 16 weeks |
1.2.1 | 2008-02-11 | 11 weeks |
1.2.1.1 | 2008-02-28 | 2 weeks |
1.2.2 | 2008-04-11 | 6 weeks |
2.0 | 2008-08-13 | 17 weeks |
2.0.1 | 2008-09-10 | 4 weeks |
2.0.2 | 2008-12-02 | 8 weeks |
2.0.3 | 2008-09-10 | 3 weeks |
So as we can see generally between bug fix releases (the z in x.y.z) the time is fairly short, slightly over five and a half weeks, and the time before a new feature release (the x or y in x.y.z) is much longer, sixteen and a half weeks and clearly if you are waiting for a bug release this is unacceptable!
It is because of this that I am changing the way Toucan releases work, rather than splitting them up into bug and feature releases they will be one and the same thing, but much more granular. For example I have often said that I am going to build a more intelligent sync and new progress box into version 2.1, this will still happen but not all at once! For example if all goes well in the next version of Toucan I intend to start on some of the background work of the improved sync and to start the updates on the progress box, possibly a progress bar to start off with. In this fashion I will aim to add new features as the releases are made; only bumping the y part of the version number when I am happy the new features are complete. In fact this granular development has already started, for example version 2.0.2 added a new back end to perform operations in Toucan and this was expanded in 2.0.3 to hopefully make the UI more responsive in Sync, as well as to display the elapsed time for an operation.
For those of you that have bothered to read this far, well done, and what do you think, should a developer go for long gaps between releases and add lots of stuff, or improve the program in little steps?
- Steve Lamerton's blog
- Log in or register to post comments
Comments
I would say don't make a new
I would say don't make a new release unless bugs are fixed, performance is increased, or features have been added/modified. If the user can't tell then why ask them to update?
If you are gradually enhancing features then by all means update more frequently.
I
think that was what I was trying to say is, rather than waiting for a giant release with a boat load of features why not release little and often, and certainly dont let the features delay bug fixes.
Whoa
I didn't wanna write a new post for this, but holy man... congrats on this.
:O Wow!
Wow!
WOW!
WOW!