[Kde-extra-gear] Evaluation of the extragear tarball releases.

[Aaron J. Seigo]

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 
kdrip-1.3.tar.bz2.

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 
version numbers.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080112/418683c1/attachment.pgp