Proposed adjustments to our release cycles

[Albert Astals Cid]

El Divendres, 15 de juny de 2012, a les 13:05:44, Sebastian Kügler va 
escriure:
> Hi all,

Hi

> 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?

My concerns:

 * Need more people to do the tarball packaging/releasing (since if you 
propose to release that often you can't expect the same person to be doing 
packages almost weekly or byweekly given the release dates won't probably 
align)

 * Uncertainity on the "current release state". We have people that don't know 
the current state of the release and commit new features or new strings when 
we are frozen, and that's with just one release schedule, i can imagine the 
mess with N different release schedules

 * The difficulty of coding for N releases. Since the releases an not aligned 
anymore, you have to maintain code and #ifdefs for new features that depend on 
new versions of parts X of the stack that may or might not be used by people 
compiling the application. We've have some bad experiences with "expected 
versions on the stack" so i hope you're understanding this is not a 
theoretical scenario.

What's your opinion on these issues?

Cheers,
  Albert

> 
> Aurelien, David, Dario, Vishesh, Alex, Aleix, Martin, Martin, Marco, Björn,
> Kevin, and