Proposed adjustments to our release cycles

[Andreas K. Huettel]

> > know the current state of the release and commit new features or new
> > strings when we are frozen, and that's with just one release schedule, i
> > can imagine the mess with N different release schedules
> 
> "Always summer in trunk". As long as releases are not created from the
> master branch it should be fine. On the other hand nobody should commit
> without a review anyway, so just commit and push without proper
> communication with the core developer group is so wrong in the first place
> 

That's actually not the whole problem. How will the feature releases of the 
constantly evolving frameworks interact with the dependency freezes of the 
applications?! 

Remember that for distributions it's far better to stick to bugfix releases of 
core libraries for a while, but feature upgrades of single applications may be 
easily doable. 

Now that means that 
* either the core libraries plus all the applications will get frozen in a 
distribution, because newer applications would need newer libraries
* or we get into branching / #IFDEF madness, because older libraries require 
other codepathis in applications

Thoughts?

Cheers, Andreas

-- 
Dr. Andreas K. Huettel
Institute for Experimental and Applied Physics
University of Regensburg
D-93040 Regensburg
Germany

tel. +49 151 241 67748 (mobile)
e-mail andreas.huettel at ur.de
http://www.akhuettel.de/research/
http://www.physik.uni-r.de/forschung/huettel/
-------------- 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/20120618/dcbcb64c/attachment.sig>