Evaluation of the extragear tarball releases.

[Tom Albers]

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