Release Script

Sun Jul 8 11:48:47 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
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] -
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=kde-base/kate/Manifest;hb=refs/heads/master
 [2] -
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-base/kate/Manifest?revision=1.309&view=markup
 [3] - ftp://ftp.kde.org/pub/kde/stable/4.8.4/src/

> 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 >
5.2.0_alpha15

 [4] -
http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 [5] - http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-160003

> Regards, - Michael Pyne
> 
> _______________________________________________ release-team
> mailing list release-team at kde.org 
> https://mail.kde.org/mailman/listinfo/release-team
> 

- -- 
Regards,

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

iQIcBAEBAgAGBQJP+XOfAAoJEC8ZTXQF1qEPUgIQAJU/5SvrbCahskGrUNjNPYNN
wyr1ctmYFEHd+lcJ0Oj9ckw4UKAkK/ohgemakRqGQtBOmC3pNWkoGQ7O/5wvTpuo
4c0bKzrtNHMNbJcxEAYe6U2w1P4oeMclS4r9rHFk8w9WYaWkWmgDHC+SO+9XY/oQ
Mhkhx5pnf/0cCc4uv9RuyxTCkfLeO6PIAWnI+4keau6Bv+V73LV35uTTlA8MqC3d
/jRTJ37YJMxT7NbXiIOQCSWnFmNSkd3dLxf1MOdm0z3i436ZL65ZONaeACW+mdHH
6VpH2OuzFv5qVNwa7yWHefAKFZERlkdC1cvRXj+5X9x47AbSBs/2fTD38ysKLmZt
b7gvpGPDTf9YmxaL1ugehtm0biinlR+2HjGN8vrwyQTRXxpleKIlmbAylFP6g+EQ
goRcTqOH1MxCE4xYGOkm8stgpgr8PAkbY/5m3ehI2ioysDWCT3/qKRy8t2O2ANNW
Mv9X72inmZ59kBUZCJN28VAZ67Bbpq767gZ6we73hwMhoPYrqbUkupI+nxbwOX+q
jl24ML4tsJ5Wq8FU2tUJVu40zjbk7WBNxizyzHz9tEK3Bc3X9P6PsNR9nKnc+nEi
3KjxLoNEj3E05kO+/op6CfQug6P8IvkxrTh5a6bS+rbJGKOCqjZwIf73JiExw/Uz
ssYpEJudFxJ3ljObVPlT
=FxTp
-----END PGP SIGNATURE-----