Re: Evaluation of the extragear tarball releases.

Op Saturday 12 January 2008 20:43 schreef u:
> > Own release schedule: ktorrent
> > KTorrent has made his own beta release between te
rc2 and final keg
> > tarballs we created. I think we should disable
ktorrent from our release
> > process for now, untill they indicate they want to
join again.
> 
> We need talk again with Joris, but remember, keg
maintainers are free to do 
> releases in between. We can push the same releases
again in the launch, no 
> issue.

Indeed it is no issue. It is perfectly fine. But if the
ktorrent authors release ~5 days after rc2, someone did a
useless excersise. I'm not really bothered by that, but it
is something we need to prevent in the future. The ktorrent
maintainers can remove or add the ktorrent application at
any time to the project page. 

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.

> > 3)
> > One of the bigger issues is the versioning.
Because they are released with
> > the kde release the internal version number of the
application should be
> > bumped as well. I would like to suggest to use the
same numbering as the
> > kde release they are part of. I've to discuss with
some people how to do
> > that, but I can add something like
'setVersion(4.0.1)' to a cmake file, and
> > try to use that in the kaboutdata and when it's
not set use the 'old'
> > value.  Any ideas (or help with the execution)
would be great.
> 
> No, definitively i'm against use this. The applications
should remain their 
> own release number. That was thr original target of keg
ans should stay this 
> way.
> We should find a better way to match the version with
our releases, and not 
> the other way.

Okido. Well let's take a made up applicatin as an example. 

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

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, as that 1) removes the need of the maintainer to do
that (likely to be forgotten)  2) solves the above problem
for the packagers.

> Meeting at Mountain VIew ?

I will not be there. 

Toma

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear

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

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear

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

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear

On Saturday 12 January 2008, Charles Connell wrote:
> That sounds like a job for a text file in
trunk/extragear!
>
> Probably the simplest way and most easily automated and
hand-edited.

probably. heck, if we make it a INI style file i could
easily whip up a small 
console app that processed it and spat out results with
ease. if we tied this 
in with the extragear packaging script ........ shall we try
that route?

-- 
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

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear