Proposed adjustments to our release cycles

[Scott Kitterman]

On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote:
> Hi all,
> 
> During our sprint in Pineda de Mar, we sat down and thought about how our
> release cycles relate to the structures in our software, we came up with the
> following proposal we'd like you to consider and provide feedback about.
> 
> Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and
> Applications each with their own release cycles. Each of these releases
> would be a set of tarballs of the latest stable versions of the application
> (or codebase in more general).
> As an example, Frameworks could release updates every 2 months, while our
> application collection is updated monthly. New iterations of the workspaces
> come every four months. (These numbers are completely arbitrary, and here
> only for illustration purpose!)
> 
> More specifically for the Workspaces, we would like to release all
> workspaces at the same time.
> 
> This model would
> 
> * Allow components to skip releases if they need to take a longer
> development cycle
> * encourage developers to have an always releasable master
> * put more emphasis on continuous integration and other automated testing
> 
> As far as we can judge, this would be in line with our communication
> strategy, and allow us to target different groups more clearly. That is
> something to streamline with the people at kde-promo, though.
> 
> Opinions?

I've read every message in this thread.  From the perspective of a 
distribution packager, I'd like to sum up my perspective on this.

Who are these releases for (what's the target audience)?  It takes effort from 
packagers to packager a release.  The level of effort is both per package and 
per release, so even without changing the release model, the move to 
frameworks, etc. is going to increase the amount of work we have to do.  I 
don't think most distributions have spare developers waiting in the wings to 
deal with all this.  Add more releases and I expect they aren't going to get 
packaged.

If the target is people who build from source directly, then are releases for 
them really necessary if there's an always 'stable' integration branch people 
can build from?

Once we get past a certain point in our release cycle and for certain in post-
release updates we can only take bugfixes.  Currently the vast majority of the 
KDE SC bug fixes we deliver are delivered via the KDE SC point releases where 
KDE developers have decided what is appropriate to backport to a stable 
release.  We need this.  For users that get KDE SC via a distribution these 
make a big difference.

There was mention of the idea of designating a certain set of releases as 
"LTS" releases that would get post-release support like current releases do.  
I think that would solve most of the packaging problems I can think of from 
this proposal.  We would likely aim to package those and use update releases 
as they became available.

Scott K