23 May 2012, 22:50

Hi All,

As discussed briefly in the Developer meeting yesterday, we (Catalyst) have drawn up a Six Monthly Release Schedule.

https://wiki.mahara.org/index.php/6MonthlyCycle

Currently the plan is:

• Each release has 16 weeks before feature freeze.

• For each release, We've put feature freeze at a month before the release candidate. Only non-feature bug fixes will be committed after this. We might reevaluate this for 1.7 if it is excessive.

• We've scheduled 3 weeks of RC before the final, but will perhaps reevaluate that to two weeks for 1.7 onwards.

• The week before the release candidates is a UI freeze. This is a freeze to string changes and theme changes. String or UI fixes will need to be at least high importance.

We hope this will help us get features to users quicker.

We are posting the plan here for feedback and discussion.

24 May 2012, 0:11

Hi all,

Kristina has just mentioned to me that we haven't set a point-release schedule in this.

We should decide whether we want to:

• Release when there are updates to release
• Have specific dates for making releases

Moodle and Koha both have set dates.

Some considerations here are:

1. How it would affect system admin schedules.
2. How often do we have point-release suitable bugs.
    a. That we currently don't release new features, and only security fixes or fixes for bugs with significant impact.
    b. Including lesser fixes can affect the maintenance overhead of keeping the easy packages maintained in the Debian and Ubuntu repositories.

24 May 2012, 18:06

Thanks for asking for input on this.

I'd prefer a release when there are specific updates or features as opposed to scheduled releases. In the case of moodle, we waited for previously announced features to be included in a scheduled release only to find out they did not make it. This makes it difficult when an organization plans around announced but not delivered features. Tabbed browsing is one of those, a better moodle-mahara integration, android mobile app are others. I guess what I am saying is that I can wait for good features to be released and do not need a firm date that can not be met for whatever reason.

There is an amazing amount of work that goes on in master and I think its too bad that people don't work with those features and fixes sooner. 

25 May 2012, 3:57

Hello Dirk,

We have not made promises about features for some time now as we have not been able to meet those promises. Even in the last 2 releases only features went in that had been through the review process. We did not promise features that had not made it to the review process yet as it is too difficult to schedule them.

How do you image it working for "when there are specific updates or features"? Would that mean whenever the release teams thinks a great feature has been added or a bunch of small features has been added that a new release would be made? Who would decide what these breaking points are? For how long would older releases be maintained? What would the maintenance of older stable releases mean? How would big institutions / large installations deal with that? Would they upgrade in the middle of the year or still wait for the summer holidays etc.? How would the upgrade path from a much earlier version be handled?

I'm not sure if you would be able to answer all questions, but these are some that pop into my mind (from my little knowledge I have in this area).

Cheers

Kristina

24 May 2012, 18:45

As you noted, fixed release dates and the now popular SCRUMM developement model are becoming standard in FOSS projects that are playing in the big time. I certainly think Mahara would be wise to go into the same path.

If Mahara is going to increase marketshare in larger organisations (regardless of sector) then IT Managers need to be able to plan around upgraes. Fit it into their maintenance schedules. The only way to do this is a model as you have suggested.

The trick with setting release dates as you are prescribing is to ensure the develpoment model and team behind it will be able to meet these dates reliably and with the content promised. And rushing things last minute without testing can also ruin this model. Something else to be aware of

In short, a big +1 from me. But want to ensure a development model is adopted that would allow for clear setting of goals for each release and a reliable hit rate for the release dates.