--===============1393090810==
Content-Type: multipart/signed;
  boundary="nextPart8702509.VWukcvbLS3";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart8702509.VWukcvbLS3
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 12 January 2008, Tom Albers wrote:
> I was just speculating that they are having their own cycle at this momen=
t,
> 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=
=20
mutually exclusive, of course. again, this is why i really like the tag ide=
a.=20
then keg+kde just becomes a collecting of the last known stable releases fo=
r=20
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 archiv=
es
> 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 relea=
se
> 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 kd=
e=20
version numer. it doesn't. ever. never. never-ever. even ever-never. (sorry=
,=20
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=20
kdrip-1.3.tar.bz2.

so the question, which i actually had posed some months ago, was how to=20
automatically extract in a standardized way what the version number of the=
=20
application is in extragear that we are packaging so that we can *automate*=
=20
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=20
version numbers then the keg+kde release tarballs must respect the app's ow=
n=20
version numbers.

so again, a question to the KEG'ers: how can we provide some metadata in a=
=20
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 =
#?

=2D-=20
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

--nextPart8702509.VWukcvbLS3
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHiWEX1rcusafx20MRAjBRAKCpqnQJHwpf+S8kK1sCv3H9RcH7KgCgpfJW
V+/yJDQEiDEWzs2Da3R/LM4=
=HWrI
-----END PGP SIGNATURE-----

--nextPart8702509.VWukcvbLS3--

--===============1393090810==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1393090810==--