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