Proposed adjustments to our release cycles

Scott Kitterman kde at kitterman.com
Sat Jun 16 05:25:26 BST 2012


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?

Speaking as a packager for Kubuntu, it's hard for me to know how this would 
work for us.

The current model serves us very well because we can tie a specific KDE SC 
minor feature version to each specific Kubuntu release and then update with 
bugfix only micro versions once they are available and tested.

If I am reading your proposal correctly, I don't see anything about a stable 
supported branch to which only bug fixes were added?  Where is the post-release 
support model in this?

Perhaps there should be a standard interval (maybe even 6 months) for all of 
KDE SC to have one temporally aligned set of releases to provide post-release 
bugfix support for?  That would allow the more rapid, less synchronized process 
you're advocating, but still give a supported target for distros to aim at.

Scott K




More information about the kde-core-devel mailing list