Time-based release management

The idea in Time-based release management is to make the release cycle as predictable as possible, planning the release of the versions in a regular basis. The classical -- and successfull -- example is the GNOME project, which releases a new version of the GNOME desktop every six months since some years ago.

Some references:

• Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management. Martin Michlmayr's PhD thesis.
• Press coverage on Newsforge about Michlmayr's thesis.

-- Contributors: AntonioTerceiro - 01 Jun 2007

Discussion

I've read Michlmayr's thesis, and think that the conditions he states for a project being able to adopt a time-based release strategy are either already met by the TWiki project or are good suggestions for it. They are:

1. Enough work gets done: with time based release management, new releases are made according to a certain interval. This strategy cannot be used in projects where there is no guarantee that enough work is done during an interval to warrant a new release
2. Distribution is cheap: since time based release management relies on the publication of regular releases, the distribution of new releases must be relatively inexpensive and easy.
3. The next release does not require specific new functionality: the main focus of time based release management is time rather than specific functionality. It is therefore not suitable for pro jects in which specific functionality needs to be delivered with the next release, which tends to be the case in traditional software development.
4. The code base and project is modular: it is important for a project to be modular because this allows individual components to be developed, fixed, released, and also taken out again independently.

Martin Michlmayr. Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management, Section 6.2 (these conditions are further explained in the rest of that section).

-- AntonioTerceiro - 01 Jun 2007

I agree - Time based is easier in many ways - and I think you will find we are releasing often enough (4.0.5 was oct 2006, 4.1.2 Mar-2007, 4.2 is planned for Jul-2007) that we could seriously look at aiming for a (non-fix only) release every 3 to 6 months.

if for example we were to aim for a (major/minor) release every 3 months, then we could aim for

• large features / refactorings are close to feature complete in the first 4-6 weeks
• feature freeze 4 weeks before release
• and then the month of test&fix - which we are in for 4.2 right now

-- SvenDowideit - 01 Jun 2007

That goes against the roadmap we agreed. To give us a year to implement the needed major redesigns for 5.0.

If we continue releasing every 3 months then we

• Piss off our customers who needs to upgrade all the time to get plain bug fixes because patch releases only go 3 months of fixes back.
• Continue feature creeping and getting nowhere with TWiki.
• Continue to lower the quality of TWiki more and more. It has so many bugs now that my users are getting totally crazy. Cairo was much more stable.

-- KennethLavrsen - 01 Jun 2007

I agree with Michlmayer's conditions, but I'm afraid I don't agree that the TWiki project meets them.

1. Enough work gets done: I know we fail here. If there were twice the number of people working on the core, perhaps. but not right now.
2. Distribution is cheap: it isn't. TWiki remains a pig to install, and not a lot easier to upgrade.
3. The code base and project is modular: we are getting there, but are not there yet. There are still spaghetti relationships between internal components that will take a long time to unravel.

Ken, you say "It has so many bugs now that my users are getting totally crazy" - I'm really quite surprised to hear you say that, as the bug database suggests otherwise. There are 9 urgent bugs against the Engine. Most bugs (71) are "Normal" which suggests they are liveable-with; the very fact that most have been ignored for long periods suggests they are not even that urgent. Most of these bugs are against MAIN, except some recent Urgents against 4.1.2 which are already fixed in MAIN. What is at the heart of this comment? Or are you just trying to depress us?

-- CrawfordCurrie - 02 Jun 2007

With respect to the number of bugs in TWiki you have to look at it not at a short split second but the experience of using TWiki over a period of time.

We ran Cairo from October 2004 and until Dakar was released. We had very few bugs. Things were quite stable.

Since installing TWiki-4.0.0 the experience has been bugs, bugs, bugs, and more bugs. And we upgrade and upgrade and install patch releases and more patch releases. Look at the release notes how many bugs we are fixing. I am not talking bugs we raise and close between releases. I am talking about bugs we do not find before the release. Since TWiki 4.0.0 the number of bugs found in released versions of TWiki is far too high.

If we start releasing from MAIN every 3 months our customers will run away screaming. I bet we need 3 months just to get 4.2.0 stable.

Right now the current level of bugs is false. Because there has been so much unfinished code in Subversion for at least two months (a practice that has to stop) most of us have not bothered to test TWiki in that period. Or to raise bugs we see. If you notice the SVN history lately in fact not many have bothered to contribute at all.

When systematic testing starts again now, many new bugs will surface.

And last and not least. The Wysiwyg editor has so many bugs that it is close to useless. And that it the feature my users see and complain about all the time as it destroys topic after topic. The Wysiwyg editing is by far the thing people complain the most about. And this is not addressed at all in 4.2.0. And that makes me depressed.

It is better to have long release cycles and release good stable products than releasing a bad product with endless list of bug patches.

The products Antonio compares with are typically compilations of "programs" that make up a Gnome or KDE or a Linux distribution. Each program may have up to 3-4 year release cycles. It is just that every 6 months the collection is updated with what is ready to be released. A very different situation from TWiki.

-- KennethLavrsen - 03 Jun 2007

I agree that TWiki is not ready for time-based releases yet.

I'm not proposing that TWiki release every 3 months, but I think we could discuss a way to have predictable releases. It doesn't need to be every 3 months, it could be every 12 months, whatever.

I won't argue for very short release cycles, but for clear and predefined release schedules. If we need to work on a major refactoring before being able to do that, that's fine.

-- AntonioTerceiro - 12 Jun 2007

I believe the way to achieve predictability is to have a roadmap. For the last three years, the PersonalRoadmap of the various developers has provided the only guide to what is planned for TWiki. I am still to this day working on the PersonalRoadmapForCrawfordCurrie that I wrote back in 2004.

But personal roadmaps are not project roadmaps. The major refactoring that is required, before we can start talking about predefined release schedules, is to introduce a culture of project roadmapping. I had hoped this had started with the concept of CustomerAdvocate? , but we have seen very little activity (at least when compared to the effort being poured into the code).

-- CrawfordCurrie - 13 Jun 2007

I totally agree with Crawford.

Those that was at the release meeting where it was decided to release a 4.2.0 may recall that I originally wanted a 5.0 beginning of 2008 (a year after the meeting) with release themes that we needed to focus on. The roadmap I wished to see and still hope we will address are

• New Wysiwyg editor
• Storage model that scales (addressing performance of TWiki and in particular searches when the number of topics reaches hundred of thousands

I know other have desired a better installer for TWiki so it becomes easier to deploy on all platforms. So easier deployment is also an obvious release theme candidate.

The reason I was hesitant to making a 4.2 was that these minor releases quickly puts focus on all the little feature expansions that people with for all good and valid reasons.

But I am very optimistic that we can get a longer term roadmap defined because key forces on the development team have shown great interest in these. Some examples.

• The debian package
• The DB storage studies and concept code
• The new performance tool
• The new query search which is an important step towards searches in indexed data.
• The TWiki cache studies
• I have forgotten many equally important steps. The above are just recent examples.

So I have no doubt that the will and interest is there. The greatest issue is resources. It is not too difficult to get a couple of thousand dollars for a little desired feature creap. But some of the tasks waiting could use that 2-3 developers gets funded for a full year to work focussed on these roadmap tasks. This may sound like a deam more than a vision but there are good reasons to believe this can become a reality.

If you look at the release process you will see that it contains the idea of a release theme. I wrote that originally and my idea was that once the community has agreed on a theme (e.g. a new Wysiwyg editor.) a number of people can work on this without having to raise every little detail of it as a feature request.

My vision of a release theme is that the community creates a couple of Codev topics describing the overall spec and idea and then the work can run without having to debate too many details. Instead we can review the work along the way in release meeting and here on Codev.

So once we have this 4.2 out of the door I will again propose not to go for a 4.3 with more small incremental features but create a roadmap with a 2-3 of release themes for a 5.0 with a release date of mid 2008 (one year after 4.2).

This does not prevent other small features to enter 5.0. But it gives focus and time to do the necessary things that will make TWiki survive and continue to be THE business wiki. Crawford is right that we Customer Advocates have not been talking roadmaps. I have personally been spending probably too much time getting feature proposals processed. And now as release manager on 4.2 that takes my time. Making a release cost all of us a lot of time. It is not just a matter of building a tgz/zip pair. And since most of us only have 1-2 hours per day for TWiki it is important what we put our focus on.

Let us put roadmap on the agenda on release meeting from now on.

-- KennethLavrsen - 16 Jun 2007