Release Script (KF5)

[Michael Jansen]

On Thursday, July 12, 2012 08:25:03 PM Martin Gräßlin wrote:
> On Thursday 12 July 2012 13:01:47 Rex Dieter wrote:
> > On 07/12/2012 12:43 PM, Martin Gräßlin wrote:
> > >> Now, I'd have a much lesser concern if modules that are part of the
> > >> 'kde
> > >> development platform' at least are never skipped.
> > > 
> > > Could you explain why?
> > 
> > So, right now I can do a very simple runtime dependency for kde apps:
> > 
> > KDE_DEV_VERSION=$(kde4-config --kde-version | cut -d' ' -f1)
> > 
> > Requires: kde-runtime >= $KDE_DEV_VERSION
> 
> My understanding is that there won't be a kde-runtime once there is
> frameworks.
> 
> But apart from that: could we start dreaming? Dreaming of a KDE where every
> application clearly defines what dependencies it has and exactly in a way
> that packagers can set up the dependencies in an automatic and correct way?
> Can we consider going forward with leaving all hacks behind us and not stop
> the fixing with the hacks being the reasons?
> 
> For me as a developer it would be much nicer if I could say that my app
> requires only version 5.x of framework bar and 5.y of framework foobar. And
> not having a generic dependency set by the packager to 5.z.
> 
> Would that change your point of view? Would it still be more difficult or in
> fact easier?

We both know i am totally with you. But let me play devils advocate here.

Maven is most sophisticated framework so far that tries to deal with 
dependencies. But instead of solving the problem they just changed their 
problems. The problem i call the maven dependency hell.

You declare your dependencies ( A >= 4.3, B >= 4.5 )
B   declares                  ( C >= 1.6,!1.7) (Because of some 1.7 bug)

And 1.7 is the latest version the problems begin. Splitting has its short-
comings. 

And in case of maven you will often have more than 3 version of some 
dependencies dependency involved in your build. It mostly happends while they 
build and download dependencies for the current project, skip to the next 
project only to notice this one needs a newer version of the dependeny.

So we have to make sure we don't get there. We have to get much better in 
declaring the dependies and KEEEPING binary and source compatibility.

And we still have to think of all our little packages as a part from the big 
package kde. Which means we should setup a global list of dependencies and the 
current version we depend on. And everyone has to adhere to the list. I mean 
mainly what currently is kdelibs, kdebase. Even if we split there we still 
have to consider it as one unit that is released independently.

Changes to the list should have a formalized process. Ask for change, 
discussion, decision here.

Apps can do what they want. 

I am willing to work on that stuff. Gimme some time.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120712/d3a85a0d/attachment.html>