Change release schedule 4.2 and schedule for 4.3

[David Jarvie]

On Wednesday 10 September 2008 1:37, Aaron J. Seigo wrote:
> sooooo .... it could look like this:
>
> 4.x development starts (marked by the branching of 4.(x-1))
> 	* libs/base developers are on trunk/
> 	* application developers would be encouraged to use trunk/ only for
> applications, but stick with the stable branch for libs/base to increase
> testing
>
> 4.x feature freeze
> 	* libs/base developer stay on trunk
> 	* application developers are encouraged to move to trunk libs/base
>
> 4.x beta releases start
> 	* 4.x is branched off of trunk
> 	* libs/base developers stay on trunk, backport fixes as they go
> 	* applications developers move to 4.x branch
>
> i wonder if we could get enough app developers to do this? to work it
> would require:
>
> * cheap branching/merging/switching branches (svn fails here, git would
> work well)
>
> * clear communication at each step (e.g. "if you are in group $FOO, run
> this command in your source tree now: $BAR")

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.

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

So I'm sceptical as to whether changes to the development model or VCS
will make a lot of difference to the numbers of people testing the latest
and greatest in kdelibs or kdebase.

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