Release Script

[Michael Jansen]

> Gentoo already supports betas, RCs, etc. in Portage though they have a
> different nomenclature (e.g. I think 4.7.0~beta1 would be 4.7.0_beta1 in
> Portage). But in order to support generic KDE snapshots that nomenclature
> shouldn't change too much across future releases. As long as it's mostly set
> one time it shouldn't be hard to generically rewrite KDE versions into what
> is used by Gentoo (or rather, rewrite the Gentoo version to the KDE version
> to find the tarball!).
> 
> All the rest is administrivia in my opinion for a packager (they can rely on
> a good-enough GNU tar since they can enforce its presence). I would just
> make sure that the only versioning info in *released* snapshot tarballs and
> directories is the version itself (i.e. no dates, no revision tags or
> commit ids).

Sorry either because i am a non native speaker or because i am missing 
something i can't follow you here. Please give a specific example of good and 
bad.

What is the version of a snapshot? Give an example. For me it is the date. 
What do you expect it to be? Just snapshot? Keep the misuse of stable version 
numbers?

Let me give some examples.

UNSTABLE RELEASES

kdelibs-4.8.5~snapshot.tgz  (symlink to the tgz or real name)
kdelibs-4.8.5~20121005.tgz
(or whoever you think they should be named)

kdelibs-4.8.5~alpha1.tgz    
kdelibs-4.8.5~beta1.tgz   
kdelibs-4.8.5~rc1.tgz 

What should the directory in the package be in that case? Examples for the 
alpha.

kdelibs-4.5.8
kdelibs-4.5.8~alpha1/
(or ???)

Anything else.

STABLE RELEASE
(It is clear here then. No change to current procedures)
kdelibs-4.8.5.tgz  -> kdelibs-4.8.5

> A final note: It sounds like we're going towards only releasing changed
> packages between updates. I think this is a wonderful idea (as I hate
> rebuilding a hojillion KDE packages on Gentoo just for a minor point
> release) but it will be very labor-intensive for packagers if we don't
> essentially do the work for them by listing out what libraries and
> applications *individual* versions are present in a given KDE SC, for each
> release. So there would need to be some kind of automated version
> extraction (perhaps individual module maintainers could provide this until
> that's available?)

We will only start doing that when we are able to do it. That means when all 
the discussion led to a result.

And i laid out my plan how to do it in a other mail. For me the only step that 
is still a bit dark is the versioning numbers. Because doing it with a script 
gives many problems you do not have when doing it manually. Especially when 
skipping unchanged modules.

I already started a class trying to implement it and hope to present it in the 
next days.  I am trying to make sure the code can handle all cases. Which 
means doing many unit test for it. The rest is just implementing.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120708/8fcfd50b/attachment.html>