Version mismatch when building trunk

[Gary Greene]

On 10/15/09 12:07 PM, "Kevin Krammer" <kevin.krammer at gmx.at> wrote:
> 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

I very much agree with this view, as I am writing a continuous build system
and would prefer not to have to monkey with the description files for a
dependency to the build all that often as it's supposed to be "setup once,
continually build after that" with as little *manual* intervention as
possible. 

-- 
Gary L. Greene, Jr.
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.