[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Proposed adjustments to our release cycles
From:       Scott Kitterman <kde () kitterman ! com>
Date:       2012-06-16 4:25:26
Message-ID: 2035064.zdNLcJVFho () scott-latitude-e6320
[Download RAW message or body]

On Friday, June 15, 2012 01:05:44 PM Sebastian K=FCgler 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 applicati=
on
> (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 workspac=
es
> 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 stabl=
e =

supported branch to which only bug fixes were added?  Where is the post-rel=
ease =

support model in this?

Perhaps there should be a standard interval (maybe even 6 months) for all o=
f =

KDE SC to have one temporally aligned set of releases to provide post-relea=
se =

bugfix support for?  That would allow the more rapid, less synchronized pro=
cess =

you're advocating, but still give a supported target for distros to aim at.

Scott K
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]