> > 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.huet...@ur.de http://www.akhuettel.de/research/ http://www.physik.uni-r.de/forschung/huettel/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team