Proposed adjustments to our release cycles

[Sebastian Kügler]

On Monday, June 18, 2012 19:21:29 Andreas K. Huettel wrote:
> > > 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?

* there are regular frameworks releases, both feature and updates
* packages on top of that specify their dependencies (i.e. KDE Apps 5.4 
  depends on KDE Frameworks 5.4 (which might by then be two months old, or so)

That's basically how it works right now, and I think it should not be changed.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9