Version mismatch when building trunk

[Kevin Krammer]

On Thursday, 2009-10-15, Matthew Woehlke wrote:

> You apparently missed the (very long) thread where it was stated that
> there would be no 'latest' branch. IOW everyone building their own qt
> will always have to do a manual checkout every time we switch
> requirements to a new branch.

Apparently I did. Been on vacation for a couple of weeks.

> This is needed to keep a clean history, but is inconvenient for everyone
> that doesn't care about that.

A clean history on development branches is hardly an excuse for breaking 
everybody's workflow who is developing downstream.

It has been possible to provide an up-to-date base for development with SVN, 
even CVS, so it is either possible with even more advanced tools or they are 
not as advances as everybody claims they are.

If it is no longer possible to track upstream development, we should have the 
policy that KDE's platform level needs to be buildable against the latest 
upstream release.

> Well, I'm not sure what wasn't coordinated. It was announced here
> (http://permalink.gmane.org/gmane.comp.kde.devel.core/60877) more than
> two weeks ago that this would be happening.

Doesn't seem to be enough time to update the developer documentation, e.g. on 
TechBase.

Obviously if somebody had a checkout/clone of a specifc version, they would be 
aware that they needed to change to a different version at some point.
However, people who are not using a specific version but rather the branch 
specifically recommended for KDE development expect that branch to be suitably 
up-to-date.

> It was; qt-kde 4.6-stable-patched has been around for some time. You are
> being surprised because there is no more 'latest' branch; you (and
> everyone else building Qt... not limited to kde-qt, even) must now
> manually change branches.

I really don't care about 'latest' branches. I really don't mind waiting for 
an upstream to reach release-candidate or release before basing my work on it.

I care about not having to hunt down arbitrary versions of build dependencies.
If the devel package of a reasonable recent distribution such as 
Debian/unstable is sufficient, great.
If an easily updatable repository like kdesupport is sufficient, why not.
If requires changing between different development branches all the time, make 
it optional until one of the two other options become available.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091015/70365fc8/attachment.sig>