Future frameworks releases

[David Faure]

On Tuesday 09 June 2015 10:01:40 Maximiliano Curia wrote:
> On 09/06/15 09:35, David Faure wrote:
> > On Monday 08 June 2015 10:07:40 Maximiliano Curia wrote:
> >> 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.
> > 
> > Hmm this sounds like a bug or missing feature in the tool you're using.
> > Surely it could be fixed/extended to be able to fetch stuff from a
> > different directory for past releases.
> 
> How do you propose that such a tool should work?
> Crawl the complete tree structure?

No, just being configurable to
 http://download.kde.org/stable/frameworks/([\d.]+)/kcoreaddons-([\d.]+)\.tar\.xz

> Use the version in the directory as the version of the files in it?
> 
> The kimap example is just one of the releases that don't quite match the
> version in the directory, kde4libs, kdepim, and till recently
> extra-cmake-modules, have/had releases that don't match the version of the
> directory.

These are not frameworks. For frameworks, "use the version in the directory as 
the version of the files in it" would work just fine.

> >> 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
> > 
> > This would make it very hard for other people who can currently just grab
> > all of KF x.y from a single directory.
> 
> That's what I meant with alternatively, so, it would be nice if we have a
> second "view" of the releases.

Ah, a whole tree of symlinks? Can be done. You could write the script to 
create these symlinks, and I could run it when pushing a release :)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20150610/9f2ca3a2/attachment.sig>