[Kde-extra-gear] Evaluation of the extragear tarball releases.
Aaron J. Seigo
aseigo at kde.org
Sun Jan 13 01:53:43 CET 2008
On Saturday 12 January 2008, Tom Albers wrote:
> I was just speculating that they are having their own cycle at this moment,
> so it might be an idea to remove ktorrent from the page for now, untill
> they again want to join the project.
having your own cycle and being part of the keg+kde releases should not be
mutually exclusive, of course. again, this is why i really like the tag idea.
then keg+kde just becomes a collecting of the last known stable releases for
ease of distribution.
> The release-team releasese kdrip-3.97.tgz which happens to have as version
> number '1.3'. Up to now the distro's have added the kdrip in their archives
> as kdrip-1.2 (latest official release). With this new release they have a
> choice. add it as 3.97 or as 1.3. Either one is a problem: 1.3: when the
> official release of 1.3 happens. they can not name it like that because it
> is already used ny the release-team release 3.97: when the official release
> of 1.3 happens, they can not name it like that because 3.97 > 1.3
the error in the above is thinking that it *ever* gets released with the kde
version numer. it doesn't. ever. never. never-ever. even ever-never. (sorry,
that last bit just sounded too good not to try it ;)
so it would go like this:
kde 3.97 also has the 1.3 version of kdrip. the tarball should be
so the question, which i actually had posed some months ago, was how to
automatically extract in a standardized way what the version number of the
application is in extragear that we are packaging so that we can *automate*
this process with some scripts.
> So, I've no solution to above problem. But _if_ the application does not do
> their own inbetween releases, it might make sense to match the internal
> version to the kde release,
that's up to the application, but if the application does not follow KDE
version numbers then the keg+kde release tarballs must respect the app's own
so again, a question to the KEG'ers: how can we provide some metadata in a
standardized fashion that says the following three things:
* whether to release the app or not?
* which branch to pull a release from?
* whether to follow the kde release #s or not?
* what the current version of the app is, if not following the kde release #?
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080112/418683c1/attachment.pgp
More information about the release-team