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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
