Change release schedule 4.2 and schedule for 4.3

[Jordi Polo]

When I first hear about the changes, I thought/understood that the new
architecture was almost decided, it was something like:

- Qt-copy, Kdelibs and probably (to be decided) kdebase in SVN , 6 months
release, nothing really changes there. (i.e. stations, not only summer)

- In SVN there will also live files with links to external repositories and
their status (may be GIT repositories, but to be decided). Status would be
an ORDERED list like development, feature freeze, strings freeze, docs
freeze, ...

- Some external (gitorous?) mechanism to let easy navigation, forking and
branching of external repositories (aiming at casual contributors?)

KDE will continue to have 6 months releases with the same phases (feature
freeze, etc.) that applies directly to everything on SVN and apply to select
the correct repository to pull the code from.
To make it clear. Let's have Kopete with a 4.2 code branch or repository and
a 4.3 repository. When feature freeze comes, if the repository for 4.3 is
not marked as feature freeze status or superior, then the 4.2 branch will be
used.
It means that any project can skip a KDE release if it is not able to be
ready on time or simply don't want to be tied to the same 6 month release
than the rest of KDE for whatever reason (Plasma?). Obviously most projects
want to release often so won't skip KDE releases.
It also means that kdelibs is the base with a known schedule and status.
Projects can release independent from KDE. Each KDE release will fetch the
last stable version of each project (much like Xorg does).
Scripts will automatically pull all the relevant outside branches, fetch the
code and build all KDE.

I was sure it was the idea someone proposed before and more or less
accepted. But reading this thread, it seems that the new development model
is far from decided. Is the "always summer in trunk" already decided?



On Fri, Sep 12, 2008 at 9:21 AM, David Jarvie <djarvie at kde.org> wrote:

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



-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080914/011bad43/attachment.htm>