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

[Charles Connell]

On Saturday 12 January 2008 07:53:43 pm Aaron J. Seigo wrote:
> 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
> #?
That sounds like a job for a text file in trunk/extragear!

Probably the simplest way and most easily automated and hand-edited.

- Charles