User:Roan/My view on release dates
From Dokeos
This text explains my view on software development. It is my own opinion, written out for having a good discussion. It is intentionally not a compromise text yet.
Basically, my view is that frequent releases have a positive effect on
- Spreading software
- Community building
- Testing, feedback and bugfixing
- Software quality
Perfection is achieved not by trying to create the perfect release, but by a constant succession of releases with incremental improvements.
If you release more often, new users will get to try better versions and they will be more likely to consider choosing Dokeos. New and old users can experiment with new versions instead of old ones, and get updates sooner. The quicker you release something, the quicker users can offer feedback on it. During the long months of 1.6 development, we didn't release any new version at al, and the Dokeos cvs contained so many bugfixes, new features, updates and improvements that the last stable version 1.5.5 looked very mediocre by comparison. Every time we release a new stable version, more people will start testing and using Dokeos.
Contents |
How to release often
Releasing software often and on time is a matter of playing the planning game well. Releases should be time-based (release at an exact time, regardless of finished features), instead of feature-based (release when all features are ready). There will always be some tool that is not finished, some feature that is lacking. No problem, that will arrive in the next version, and waiting won't be long when you release often. When you release only once a year and a feature does not make it, that is frustrating. When you release 4 times a year, it's no big deal. The only reason to delay a release should be the existence of critical bugs: e.g. bugs that cause data loss, that make it impossible to install the software,...
Releasing at an exact time does not mean you release every year on June 6, at 12:50 pm. But close. When you announce this and clearly enforce it, developers will grow into this schedule after a while and it will become more natural. This will for the most part eliminate the continuing delay problem where developer A asks for a delay because something is not ready, then when dev A is almost ready, dev B notices a tool that simply cannot be released, then dev C has a new feature 99% ready and wants to include it as well... It is important to note that this is not a problem with individual developers or features, the problem is a structural one.
Dokeos will probably end up with a quicker release schedule in the end anyway. We have branched the CVS when we release the stable 1.6 (this branching was later then originally decided). From then on we can release more often bugfixes from the stable branch, while also working on the unstable branch.
The ability to release often also depends on the ability to quickly create the necessary installation and upgrading systems. This means
- documentation - specifically the installation guide: changes can be made quickly, but it takes time to contact the translators and see the localised guides get translated as well.
- install / upgrade system - we're currently improving this system (see forum topic on install / upgrade system) to make it easier to create good upgrade scripts.
Practical: Dokeos release schedule
We have released Dokeos 1.6 in July. At that time, we branched the CVS into the 1.6-bugfixing-stable branch and the 1.7-development-unstable main branch (or trunk).
Development of the 1.6 branch
Two of the core developers are appointed as "managers" / "drivers" / "responsible persons" for this branch. All developers with CVS access are welcome to commit bugfixes to this branch, but these two are responsible. (Two just seems a good number considering the current amount of core developers, the exact number is not the issue). These people need to have one extra bit of authority: they need to be able to refuse or remove changes from the stable branch again. This is necessary if a developer commits something that is not stable and tested. Normally, undoing changed by aonther developer is not something easily done, it will usually need discussion first and might lead to heavy arguments. For an unstable branch it is no problem if things take weeks to discuss, but for a stable branch we need to guarantee stability. A stable branch should be treated like it could be released any time.
This branch only accepts bugfixes, security updates and perhaps minor improvements upon tools if they cannot damage the core of the system. E.g. an extra search box in some tool or an updated stylesheet are fine, since they do not need structural changes or new database tables and there is little risk of them causing other things to stop working. What is not good is e.g. a new tool, a feature that requires a new table, or the replacing of all SQL calls to use a new database function -> that has to go in the unstable branch.
This branch will frequently release new versions: 1.6.1, 1.6.2. Since we do not integrate anything new that might damage the structure, there is less testing needed and those two devs can be responsible for this. They will of course work with community members / users / customers who are willing to test. Let's say a release once a month. If something would go wrong (really bad security problem), we release as soon as the problem is fixed.
I'm not sure how long this would have to continue: perhaps we can in general go up to three bugfix releases and then see what's necessary. That would mean going up to 1.6.3, and after that these two devs can concentrate more on the unstable branch, unless there are serious bugs. These releases need to be accompanied by good changelogs, to help people who modify their systems. Developer and community interest, and the release date of 1.7, will determine the amount of time we'll spend in this branch. Currently interest is high and a lot of bugfixes are being applied in this branch.
- bugfixes
- consistency changes (like the ":" in form labels etc)
- register_globals fixes
- translation improvements
- no database changes
- no filename changes
- no changes in api function interfaces
- no new language variables
Development of the 1.7 branch
This branch releases a new version after 6 months. This could mean e.g. 5 months of development, then release weekly beta versions, and at the start of the sixth month, we would release a stable version. (Or one release candidate, then the stable version)
Developers work as much as possible in the CVS. This branch is unstable so it can take a few problems. Developers preferable commit changes at least every day, even when things are not finished.
We could have two releases every year, which is perhaps rather quick, but it's possible. On the other hand, we could have three releases every two years, which is about what we have had so far. The problem with this is that the release dates will not always fit in nicely with everyone. Imagine a new release in July, August, or September, most schools and univesities will feel frustrated that they have to use an 8 month old release then.
Further development When 1.7 is released, the 1.6 branch is no longer being worked on, unless there are some community members willing to do this for specific reasons (suppose 1.7 would require new versions of --- and some people don't want to upgrade). The logic continues: the 1.7 branch splits in two, one becoming the stable-bugfixing branch that will produce 1.7.1, 1.7.2 and 1.7.3 and the other becoming the 1.8-development-unstable branch.
Advantages of this approach
- Consistent, predictable release schedule, which comforts decision makers, customers, users expecting frequent releases
- Frequent releases cause more users to be able to test new features and fixes faster, so more bug reports and feedback reaches us earlier
- Mistakes are not as big a problem and are easy to fix
- Frequent minor updates ultimately result in less bugs than less frequent major updates
- New users always have a more or less recent version to test
- Community growth[/list]
Contrary to what people may think, releasing twice a year is not twice as much work as releasing once every year. It simply means every release will have less new features, but will occur more frequently. When a feature misses a release, it probably gets released six months later. Sometimes this will be frustrating, but in the larger picture this is no big deal.
The unstable branch probably needs some people who take care of the organising too, just like the bugfixing branch: reminding people of deadlines, announcing "freezes", etc.
Inside each release loop
We need a clearer view on
- when to stop adding features (feature freeze)
- when to stop adding new translation strings (translation string freeze)
- when to stop adding anything except very important patches and fixes (deep freeze)
You can also see this in a more organic way: as the release aproaches, changes become more costly, so development loses some agressiveness - anything goes, big changes, refactor mercilessly - and becomes more careful. Perhaps establishing exact dates for these freezes would be overkill and actually harm development, I don't have experience with this yet.
The Dokeos company and release schedules
Some business people might find that releasing that often is somehow harmful to business since it appears that no release is ever stable and needing constants updates might be seen as a weakness instead of a strength.To me these arguments do not seem true, but let's ignore that and find a simple solution: let the development and releases continue at a pace the majority of the community can agree on, for example two releases every year, three releases every two years...
Solution 0 - no special case The Dokeos release schedule is set,, according to some view on releases and taking the user wishes into account. Everyone sticks with it. This does mean in a feature freeze no radical changes or new features are allowed, not even from the Dokeos company.
Solution 1 - 6 month community, 1 year Dokeos.com release schedule
The Dokeos company can "bless" only some of these releases and only take those into account for its customers, official support, and upgrades.
This compromise, or a two-way path, fits both the commercial needs of Dokeos company and the non-commercial needs of some other parts of the Dokeos community.
Perhaps this needs a naming schedule: Community releases, Dokeos company official releases? I have no clear idea of this need at the moment.
Solution 2 - short-lived separate branch
Since we have started to use multiple branches, this can also further protect us from other unwanted changes: sometimes the Dokeos company has to have a certain feature ready at a certain time for a paying customer, but this conflicts with the normal release schedule: e.g. the development is in release candidate stage and no sudden changes are desired (nor should they be allowed). Then the Dokeos company could create a temporary branch and integrate the changes in there instead of in the branch that is now in release candidate stage. Or perhaps if we branch at beta time for a release, the Dokeos company could use the main branch for its development, which eliminates the need for an extra branch.
In short, solutions enough that can solve the conflicts we've had in some releases.
The installation and upgrade code is also slowly improving, which means updating these scripts for new releases is getting easier and hopefully also less error-prone.
A look at some other software projects
Two of the most popular Linux distributions, Ubuntu and Fedora, the GNU desktop environment Gnome, and the OpenBSD operating system, all have 6 month schedules for major releases (and also have updates available in between). A lot of open source products release even more often. Gnome even release version 2.10 exactly to the day 6 months after 2.8, an impressive achievement. In contrast, KDE has approximately a 5 month / 2 month release schedule, but they do allow long delays for features. Debian GNU/Linux used to have a "done when it's done" philosophy, but they want to change this, since their last release took them three years.
Apart from these release packages, the linux and BSD distributions are updated almost daily when new versions of packages arrive, or security patches are applied.
Free software vs non-free software
It is common for opensource tools to have very frequent updates. Multiple times a year, sometimes multiple times a month, each time with small or large improvements. Sometimes just bugfixes or security fixes. Non-free software is often released much less often, e.g. once a year or one release every two years.
Opensource development
People not used to opensource often frown upon these nearly constant updates to opensource software. However, you should see this in the light that open source developers work with a different approach to software.
- we care a lot about the software and its users and want everyone to be able to enjoy the latest improvements
- we take security problems seriously and want to release fixes as soon as possible
- we want to spread free / open source software
- we often work on Linux, which has superior update tools compared to e.g. Windows. Upgrading all your installed software is just one command or mouseclick on Linux. Windows does not have such a system. There could be an automated updater for Dokeos also.
