Change release schedule 4.2 and schedule for 4.3

[David Jarvie]

On Thu 11 September 2008 17:41:13 Aaron J. Seigo wrote:
> On Thursday 11 September 2008, David Jarvie wrote:
> > For application development, the biggest obstacle to updating
> > kdelibs/kdebase (whether by moving between branch and trunk, or simply
> > updating the existing checkout) is not updating the SVN checkout (which
> > if you have a broadband connection is easy), but rebuilding and
> > reinstalling once the code has been checked out.
>
> this is where having an SCM that can pull changes between branches without
> touching *every file* is pretty important. with an decent SCM when one
> switches branches it should only rebuild what's actually different between
> the branches.
>
> obviously this is more than "no changes" but it should be less than what it
> would be right now with our current SCM solution.
>
> > If the application needs new features in kdelibs, then updating is
> > obviously necessary. But if it doesn't need new kdelibs features,
> > rebuilding is a risky and often time consuming process which brings no
> > real benefit to developing the application.
>
> ... aside from identifying bugs in the libraries it depends on before those
> bugs are passed on to your users.

I agree that it's important to build up-to-date libraries at some stage before 
a new release to test that applications still work properly with them.

> > If I'm doing application work,
> > I'd rather spend time dealing with build or dependency problems, bugs or
> > functional changes in kdelibs/kdebase only when really necessary rather
> > than every week or two. A constant non-updating environment to work in is
> > the most productive, regardless of whether it's trunk or 4.x branch.
>
> right, so what i suggested is that we put app developers who want/need this
> onto the most-stable-but-still-development branch at all times: stay on 4.x
> branch until trunk is declared feature frozen, then when trunk is branched
> for the 4.(x+1) move to that.
>
> this is a way for app developers to help out by testing without causing
> more grief than necessary for them, as they won't be following a hot branch
> at any point.

All I'm saying is that building libraries isn't something that a lot of 
application developers will necessarily want to do often, whether or not it's 
made easier to do (because there is always some potential for problems). Your 
suggestion might improve things a bit, but I'd be surprised if it would make 
a huge difference. Application developers' main focus is inevitably on their 
applications rather than the libraries.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm