Release Strategy Proposal

[Andreas K. Huettel]

Am Samstag, 27. April 2013, 09:51:19 schrieb Aaron J. Seigo:
> On Friday, April 26, 2013 18:36:07 Scott Kitterman wrote:
> > It matters less that workspace is frozen if applications aren't, but
> > unlike
> > kdelibs, users see the workspace.
> 
> yes. which is why we don't want to just ship a 4.12 and 4.13 with virtually
> no changes to kde-workspace without an explanation for why development has
> suddenly stopped.
> 
> we will continue working on bug fixes and other polishing and improvement
> work, we just won't be focusing feature work there. i'd rather be straight
> forward with our users as to why this is happening.

This all sounds *exactly* like the discussion when kdelibs went into 
maintenance mode. And even there, the sudden change of policies ("current 
branch is not master anymore, version numbers do not increase") lead to a big 
mess. 

Please, everyone, do not confuse policies and practicalities. 

I fully support the idea that larger parts of "what used to be called KDE" 
enter maintenance mode for easing the transition to "frameworkx". This is a 
*policy*. 

However, there is _absolutely_ _no_ _need_ that new rules (i.e. "no new 
features, only bugfixes") must lead to changes in versioning scheme. Or even 
changes in branch names. Just declare "master only accepts bugfixes in modules 
a,b,c from now on". 

By re-organizing versioning and packaging scheme again, you are just making 
things difficult again for yourself and the rest of the world.

I am all for just continuing the current release and release numbering 
process, with the same types of git branches, while just behind the scences 
declaring more and more parts "feature-frozen".

-- 
Andreas K. Huettel
Gentoo Linux developer 
dilfridge at gentoo.org
http://www.akhuettel.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130428/db10c99e/attachment.sig>