<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 10:35 AM, Christian Mollekopf <span dir="ltr"><<a href="mailto:chrigi_1@fastmail.fm" target="_blank">chrigi_1@fastmail.fm</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Tuesday 09 June 2015 10:28:48 Christian Mollekopf wrote:<br>
> On Monday 08 June 2015 10:07:40 Maximiliano Curia wrote:<br>
> > On 08/06/15 01:28, David Faure wrote:<br>
> > > The thread "Versioning of Frameworks" on kde-frameworks-devel has led to<br>
> > > the idea that some future frameworks (coming from the kdepim world)<br>
> > > would<br>
> > > not be part of every Frameworks release, and would have their own<br>
> > > versioning scheme. This is at the request of their maintainer,<br>
> > > Christian,<br>
> > > CC'ed.<br>
> > ><br>
> > > For example:<br>
> > >   KF 5.12 would contain KImap 2.1<br>
> > >   KF 5.13 would not contain a KImap release<br>
> ><br>
> > That's the same as including KImap 2.1 in KF 5.13, so, why not adding the<br>
> > additional file to the KF 5.13 release (even though it hasn't changed)<br>
><br>
> Tooling problems aside (I don't know about those), that should indeed work<br>
> perfectly fine and would mean packagers can simply grab the latest set of<br>
> tarballs, ignoring what the versions look like.<br>
><br>
<br>
</span>Assuming you packaged KIMAP 2.1 in the KF 5.12 release, not releaseing a KIMAP<br>
in the KF 5.13 release would still result in having KIMAP 2.1 available from<br>
the last round, wouldn't it? I can see how that could result in problems if<br>
you're not working on top of an existing repository and essentially have to go<br>
through all KF releases to find all libraries.<br>
<div class=""><div class="h5"><br></div></div></blockquote><br></div><div class="gmail_quote">What's the point of that?<br><br></div><div class="gmail_quote">If Kimap is is not updated from 5.12 to 5.13, just include 5.12's in 5.13. Otherwise:<br><br></div><div class="gmail_quote"><ul><li>Users will need to go through all KF releases to find the library they are looking for.<br><br></li><li>What happens if a library is updated in, say, 5.12, but it is no longer updated until 5.18?<br><br></li><li>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.<br><br></li><li>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.<br><br></li><li>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?<br></li></ul></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div>-- <br><div class="gmail_signature">Pau Garcia i Quiles<br><a href="http://www.elpauer.org" target="_blank">http://www.elpauer.org</a><br>(Due to my workload, I may need 10 days to answer)</div>
</div></div>