next release and release pace in general

Boudewijn Rempt boud at valdyas.org
Tue Feb 12 08:22:07 GMT 2013


On Sunday 10 February 2013 Feb, Cyrille Berger Skott wrote:
> Hi,
> 
> Here is my opinion on release schedule. First, we have to go back and think 
> about why we do release ? And more important, to whom we do release ? For me, 
> it is obvious that we primarly release to bring improvements to our users, 
> everything else is and should be a side effect.
> 
> == Targeting users
> 
> Then we have to know our users, and the following is based uniquely on my 
> experience with talking with other people, technical, and non-technical, young 
> or older, if someone had a study on the subject, I would be very interested to 
> read it, but anyway, I would say there are two categories of users, those who 
> don't want any changes at all in the software they use and those who like to 
> see improvements. Personnaly, I think that when we release, we can safely 
> ignore the first group of users, there is no law that say that a user have to 
> upgrade, hence that group of users is well served by a fast or a slow release 
> cycle.
> 
> For the second group of users, it seems to me, that they appreciate 
> improvements, weather features or bug fixing, and would strongly dislike 
> disruptive changes (major UI overhaul and regressions). But to be honest, that 
> would be true for any release schedule length. To be honest, based on that, I 
> would even be suggesting monthly release, continuously bringing features and 
> bug fixing, but that would be a QA nightmare.

If we want to provide users with improvements, we need to have users in the first place. That's simply not the case, and in order to get more users, we have to be able to tell them what is available. The only moment we can do that is in with a release, because only releases get picked up by press and news sites.


> 
> == The competition
> 
> This assumptions about users appreciating continuous non-disruptive 
> improvements, that have led Google to release Chrome every six weeks, Firefox 
> is also now following that schedule. The Linux Kernel get a major release 
> every four weeks. If you look at web site and web applications, they get 
> continuous improvements that are silently rolled to users. This is the current 
> trend in the industry, release early and release often.

But those projects are not the competition. The competition is LibreOffice (just had their 4.0 release with lots of coverage and a very nice special website landing page for 4.0), MS Office, GIMP, MyPaint, Photoshop and so on. None of these projects are on continuous releases, and they all use their releases to generate publicity.

> 
> == Splash
> 
> I don't think release should be used for making a "splash", I fail to see the 
> benefit for our users, also, we would have to define what is a "splash", same 
> with defining important features: what is an important feature for someone is 
> completely unimportant for someone else, also, developers tend to vastly 
> overestimate the time it will take to complete a feature, which is the problem 
> with goal-oriented features, they keep dragging on, waiting for some features 
> to be finished.
> 
> So yes, our releases announcement looks like they don't contain so much. My 
> suggestion would be that once a year we write (rather collect) a small leaflet 
> with all the new features and improvements that have happen during the last 
> year, pretty much like Krita's leaflet (http://krita.org/aboutkrita26.pdf). 
> And then we send that to the press, along with a presskit, and I am rather 
> convinced that it will be much more efficient at attracting attention than 
> waiting for having sufficient features to do a release.


This is the point where I disagree most with you: if want to get more users and more developers we have to get publicity. And basically, apart from bad stuff happening like forks, releases are the only hook news sites and press acknowledge for writing about an application.

I think making a splash is actually the most important thing of a release. Just look at the amount of interest the 2.6 release has just generated for Krita.


> 
> == Reaching users
> 
> Fedora and Ubuntu are on a six months schedule with freeze early March and 
> early September. OpenSuse is on a 8 months schedule. However, rolling 
> distributions are getting increasingly popular, with Gentoo and ArchLinux, 
> Debian has started discussing it, Ubuntu is rumured to introduce it soon. Also 
> most distributions offers backport of the latest software.
> 
> And that is only Linux, but the hard truth is that if Calligra become 
> successful, most of its users will be Windows user, where we are not dependent 
> on distributions release schedule.
> 

That is not reaching users: it's making software available. It's perfectly possible to make our software available regularly and still reach basically no-one.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl



More information about the calligra-devel mailing list