Future frameworks releases

Maximiliano Curia maxy at debian.org
Mon Jun 8 08:07:40 UTC 2015

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:

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

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:

Happy hacking,
"Brilliant opportunities are cleverly disguised as insolvable problems."
-- Gardener's Philosophy
"The reverse is also true." -- Corollary
Saludos /\/\ /\ >< `/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/release-team/attachments/20150608/6b01d9be/attachment-0002.sig>

More information about the release-team mailing list