> 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
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team
