Proposed adjustments to our release cycles

Andreas K. Huettel dilfridge at
Mon Jun 18 17:21:29 UTC 2012

> > 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 

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


Cheers, Andreas

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

tel. +49 151 241 67748 (mobile)
e-mail andreas.huettel at
-------------- 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: <>

More information about the release-team mailing list