Release Script

[Michael Jansen]

> Speaking in the apps side (not frameworks)
> 
> I think it makes sense to release anyway since we are using the version
> numbers of SC for the tarballs (which might not be a good idea), but i would
> feel confused if this happens
> 
> 4.9.0 gets releases of
> kalgebra-4.9.0.tar.xz
> ktuberling-4.9.0.tar.xz
> okular-4.9.0.tar.xz
> 
> 4.9.1 gets releases of
> okular-4.9.1.tar.xz
> 
> 4.9.2 gets releases of
> kalgebra-4.9.2.tar.xz
> ktuberling-4.9.2.tar.xz
> okular-4.9.1.tar.xz
> 
> As a user i'd think, what happened to kalgebra-4.9.1.tar.xz and
> ktuberling-4.9.1.tar.xz ?


One solution would be to release 4.9.1 of ktuberling and kalgebra with KDE SC 
4.9.2 . Since the first number is the app version and the second number is the 
KDE SC Version. Which only look related in this example but on a config 
management scale are unrelated.

I am just wondering about the distros again. Say i release KDE SC 4.9.2 and of 
all our packages only 10% got really changes. I wonder how that affects the 
workload if we force a release of the 90% unchanged ones. Or do they need them 
to be released?

Yes this is a unlikely number but remember with kde frameworks we split up 
kdelibs in a thousand packages. Let them mature a bit and we will get there.

For now i will ignore that. The script should be able to handle both cases and 
configurably so.

I think we have talked about everything i wanted to talk about. I will start 
with the release building script.

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