[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-extra-gear
Subject:    Re: [Kde-extra-gear] Evaluation of the extragear tarball releases.
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2008-01-13 0:53:43
Message-ID: 200801121753.43831.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

["signature.asc" (application/pgp-signature)]

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gear@kde.org
https://mail.kde.org/mailman/listinfo/kde-extra-gear


[prev in list] [next in list] [prev in thread] [next in thread]