Future frameworks releases

Christian Mollekopf chrigi_1 at fastmail.fm
Tue Jun 16 19:43:56 UTC 2015



On Tue, Jun 16, 2015, at 05:12 PM, Cornelius Schumacher wrote:
> On Tuesday 16 June 2015 11:25:07 Christian Mollekopf wrote:
> > On Wed, Jun 10, 2015, at 11:56 AM, Cornelius Schumacher wrote:
> > > 
> > > For example for Inqlude I currently have a tool, which updates the meta
> > > data
> > > of all frameworks with each release. It only works because it can assume
> > > that
> > > the version numbers are the same for all libraries. With different
> > > version
> > > numbers I would have to implement some checking of available tarballs,
> > > parsing
> > > version numbers, etc. Doable but more complex and some effort.
> > 
> > I don't know the script, but if it i.e. would just gather the latest
> > release tarballs,
> > then you could continue to ignore versions if the full set of tarballs
> > is made
> > available somewhere.
> 
> The script is here:
> https://github.com/cornelius/inqlude/blob/master/lib/kde_frameworks_release.rb
> 
> What you propose is possible, but would add complexity. I wonder how a
> patch to this script would look like, but it wouldn't be a trivial change.

I don't know much about ruby, but from what I could gather the script
goes through a list of libraries,
that are gathered from the inqlude-data repository, and generates for
each a manifest file,
that among other information also contains the version?

The version seems to be part of the generic manifest, as well as the
source tarball name.

Naturally you don't want to maintain the individual version numbers in
inqlude-data.

I think as part of each frameworks release, we could publish a similar
manifest,
i.e. http://download.kde.org/stable/frameworks/#{version_dir}/manifest,
where version_dir is the frameworks release number.
The manifest could be a simple list of $framework $version:
kimap 2.1.0
kcalcore 1.0.1

The frameworks tarballs themselves can continue to be made available
through
http://download.kde.org/stable/frameworks/$framework-$version.tar.xz.

So yes, it would be a bit more work for that script, but not a whole
lot, or would it?

Cheers,
Christian


More information about the release-team mailing list