Release Script

[Michael Pyne]

On Saturday, July 07, 2012 22:22:38 Michael Jansen wrote:
> On Saturday, July 07, 2012 04:04:42 PM Michael Pyne wrote:
> > On Saturday, July 07, 2012 18:27:42 Jorge Manuel B. S. Vicetto wrote:
> > > >>> I think we did it for a time. At least i remember some " a new
> > > >>> snow storm, a new snapshot" commits by dirk. But no idea how
> > > >>> they got released/packaged.
> > > >> 
> > > >> Yes, you did that in the past and we really disliked it.
> > > > 
> > > > Could you find out how they were named back then for me? Just for
> > > > information.
> > > > 
> > > > Mike
> > > 
> > > I can't recall the names used back then, but I'm pretty sure they
> > > included the svn id in the names and dir inside the tarball.
> > > I tried asking in #gentoo-kde but no one got back to me so I can't
> > > help with that.
> > 
> > You can look at ftp://ftp.kde.org/pub/kde/snapshots/ for an example of 
what
> > they used to look like (packagename-svn-$revno.tar.bz2).
> > 
> > This was made easier by later having symlinks available (packagename-
> > svn.tar.bz2) (added by myself :P, see svn revision 458465 of kde-
> > common/release/dosnapshot) but I can confirm it was a pain in the ass from 
a
> > scripting perspective.
> > 
> > Of course for packagers they wouldn't be using Subversion snapshots but
> > plain tarball snapshots, although those suffer the same issues. In fact it
> > was worse because the directory name that was extracted to was
> > unpredictable (e.g. kdeadmin.tar.bz2 extracts to kdeadmin-1233410/).
> 
> (Sorry for the other empty mail. Wrong button)
> 
> So there is the problem i couldn't see. The directory name it extracts to is 
considered to be the same as the name of the archive. Just extracted our 
kdelibs 4.8.3 package and the dir is kdelibs-4.8.3. Build-tool already solves 
that problem by always using "tar --strip-components=1 --directory=<empty dir 
named like that module>". That's why i failed to see the problem.
> 
> Is that naming a must?

I think the issue is less about having the version component in the name and 
more that if there is a version component, that it is easy to piece toward the 
tagged version.

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).

For actual Git snapshots Gentoo uses a separate scheme anyways that even uses 
git directly, so that shouldn't pose much drama. But I don't think that's 
what's being discussed here. :)

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?)

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120707/ada22297/attachment-0001.sig>