Release Script

Jorge Manuel B. S. Vicetto jmbsvicetto at
Sun Jul 8 11:48:47 UTC 2012

Hash: SHA1

On 08-07-2012 01:56, Michael Pyne wrote:
>> On Sunday, July 08, 2012 02:30:13 Michael Jansen wrote:
>>> 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).
>> 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?
> For a beta or RC, just use that version tag with no date (e.g. 
> kdelibs-4.9.0~rc1). There would be no symlink to this as it's a
> real "release", not a snapshot. For the extracted directory name I
> would include the version name as that seems to be the standard
> style (I do that with my own software releases at least).

I like the current use of >= X.7.50 to denote versions leading to a
proper release (X.Y+1.0). But if you want to change that, in Gentoo we
support alpha, beta, pre (pre-release), rc (release candidate) and p
(patch) versions.

> For a routine nightly snapshot, use the date as the version, with a
> symlink to that module on the FTP server. The symlink name should
> mention that it's a snapshot of some sort (e.g. kdelibs-git.tar.bz2
> -> kdelibs- git-20120706.tar.bz2). If it is very important to know
> which git commit was tagged, that can be added to the source just
> before it is tarred up, similar to how README.svn-nightly was added
> to our svn snapshots.

One thing that is very important to us for any version that has a
tarball and doesn't pull directly from a repository is that it has a
stable / unique checksum. So having a 4.10.50_snapshot release that
changes every week is a no go to us. If you want to provide a symlink
in the FTP server with that name, that doesn't affect us, as we will
have to fetch the exact tarball and not that generic symlink.
The use of dates on the version number is something we can work with.
As you're talking about automated releases, it would make our live
easier if you did the release at a specific weekday (assuming weekly
releases), but if you can use the same date for all components that
are released, we can work with that.
As you can see on [1][2] we keep a checksum of the tarballs in a
Manifest file so that users can be sure the file they got is the same
we used - that help us with broken mirrors and preventing cases where
files are tampered. For the latter case having a file with checksums
for all your tarballs[3] on your FTP site would be a great help.

 [1] -;a=blob_plain;f=kde-base/kate/Manifest;hb=refs/heads/master
 [2] -
 [3] -

> For the purposes of scripting, if it's OK to assume GNU tar then
> the extracted directory name can include the date since we can use
> --strip-components. But that option is non-POSIX. Plus there could
> easily be non-shell tarball handlers (e.g. Ruby or Python) where
> you might want to know what the extracted directory name should be.
> So unless there's a compelling reason otherwise I would recommend
> leaving any version information out of the extracted directory name
> (e.g. kdelibs-git-20120706.tar.bz2 would decompress to just
> kdelibs)

To us it would be easier if the directory name matches the package
name (kdelibs-4.8.10-beta-20120726.tar.bz2 ->
kdelibs-4.8.10-beta-20120726), but if you define it will always be the
basename (kdelibs) it also works for us.

Given all the discussion about versions in this thread and to make
sure the rules work well for all the distributions affected, perhaps
it's time someone presents a table of versions and how they compare.

In the case of Gentoo, our simplified rules[4][5] are the following:

5.2.1 > 5.2.0 > 5.1 > 5.0.9 > 5.0.0 > 4.9.50

we allow the use of suffixes with the following meaning:

_alpha 	Alpha release (earliest)
_beta 	Beta release
_pre 	Pre release
_rc 	Release candidate
(no suffix) 	Normal release
_p 	Patch level

which compare as:

5.2.1_p1 > 5.2.1 > 5.2.0_p20120320 > 5.2.0_p20120318 > 5.2.0 >
5.2.0_rc20 > 5.2.0_rc10 > 5.2.0_pre2 > 5.2.0_beta6 > 5.2.0_beta5 >

 [4] -
 [5] -

> Regards, - Michael Pyne
> _______________________________________________ release-team
> mailing list release-team at 

- -- 

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the release-team mailing list