Future frameworks releases

[Pau Garcia i Quiles]

On Tue, Jun 9, 2015 at 10:35 AM, Christian Mollekopf <chrigi_1 at fastmail.fm>
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?

   - 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20150609/4dae78c8/attachment.html>