On 08/06/15 01:28, David Faure wrote: > The thread "Versioning of Frameworks" on kde-frameworks-devel has led to the > idea that some future frameworks (coming from the kdepim world) would not be > part of every Frameworks release, and would have their own versioning scheme. > This is at the request of their maintainer, Christian, CC'ed.
> For example: > KF 5.12 would contain KImap 2.1 > KF 5.13 would not contain a KImap release That's the same as including KImap 2.1 in KF 5.13, so, why not adding the additional file to the KF 5.13 release (even though it hasn't changed) > KF 5.14 would contain KImap 2.1.1 > KF 5.15 would contain KImap 2.2 > Would that work for you guys? Since you ask about it, the tool used in Debian to fetch upstream releases (uscan and watch files) expects to be able to fetch a list of files with a single request (something like https://pypi.python.org/simple/isodate/), so it better for us to have all the releases of the same package in the same subdir. The current layout of releases: http://download.kde.org/(?:un)?stable/frameworks/([\d.]+)/kimap-([\d.]+\.tar\.xz Works only for the latest release, but is not able to fetch a particular release, and it will require to convert this simple tool into a full pledged crawler. If the file is not in the latest release, then uscan will mark it as an error for that release. So, it would be better for Debian if the releases are alternatively distributed in a layout of the form: http://download.kde.org/simple/kimap/kimap-([\d.]+)\.tar.xz Happy hacking, -- "Brilliant opportunities are cleverly disguised as insolvable problems." -- Gardener's Philosophy "The reverse is also true." -- Corollary Saludos /\/\ /\ >< `/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
