[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:       Tom Albers <tomalbers () kde ! nl>
Date:       2008-01-13 0:08:17
Message-ID: 1503484.mFi0I8oaF8 () kde ! nl
[Download RAW message or body]

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-gear@kde.org
https://mail.kde.org/mailman/listinfo/kde-extra-gear


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