On Tue, Jun 9, 2015 at 10:53 PM, Pau Garcia i Quiles <[email protected]> wrote: > > > On Tue, Jun 9, 2015 at 10:35 AM, Christian Mollekopf <[email protected]> > wrote: >> >> On Tuesday 09 June 2015 10:28:48 Christian Mollekopf wrote: >> > On Monday 08 June 2015 10:07:40 Maximiliano Curia wrote: >> > > On 08/06/15 01:28, David Faure wrote: >> > > > The thread "Versioning of Frameworks" on kde-frameworks-devel has >> > > > led to >> > > > the idea that some future frameworks (coming from the kdepim world) >> > > > would >> > > > not be part of every Frameworks release, and would have their own >> > > > versioning scheme. This is at the request of their maintainer, >> > > > Christian, >> > > > CC'ed. >> > > > >> > > > For example: >> > > > KF 5.12 would contain KImap 2.1 >> > > > KF 5.13 would not contain a KImap release >> > > >> > > That's the same as including KImap 2.1 in KF 5.13, so, why not adding >> > > the >> > > additional file to the KF 5.13 release (even though it hasn't changed) >> > >> > Tooling problems aside (I don't know about those), that should indeed >> > work >> > perfectly fine and would mean packagers can simply grab the latest set >> > of >> > tarballs, ignoring what the versions look like. >> > >> >> Assuming you packaged KIMAP 2.1 in the KF 5.12 release, not releaseing a >> KIMAP >> in the KF 5.13 release would still result in having KIMAP 2.1 available >> from >> the last round, wouldn't it? I can see how that could result in problems >> if >> you're not working on top of an existing repository and essentially have >> to go >> through all KF releases to find all libraries. >> > > What's the point of that? > > If Kimap is is not updated from 5.12 to 5.13, just include 5.12's in 5.13. > Otherwise: > > Users will need to go through all KF releases to find the library they are > looking for. > > What happens if a library is updated in, say, 5.12, but it is no longer > updated until 5.18?
From a sysadmin point of view - please do this. Otherwise i'll have to double check and keep older versions of a particular Frameworks release around when archiving things (moving to the Attic) for download.kde.org. > > Forget about packages, think about users who want to build KF from source. > It will be a nightmare. Individual users who want to use KImap in their > projects will believe KImap has been retired from KF because it has not been > updated in a long time. > > Further, how will users know when a library has actually been retired? The > release notes? In my experience, release notes tend to declare things > obsolete, deprecated or retired only a long time after that has effectively > happened. > > Moreover: how will you ensure source compatibility of KImap from KF 5.12 > with KF 5.13 if KImap is not updated, not included, and maybe even not > tested? > > > I'd say what you actually need is a policy of "libraries in KF 5.13 could > have a version number different than 5.13". We had this problem with kdelibs > in the past: workspace was updated but kdelibs were not, yet kdelibs got its > version number bumped for some reason I cannot remember. > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) Thanks, Ben > > _______________________________________________ > release-team mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/release-team > _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
