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