Future frameworks releases

[Ben Cooksley]

On Tue, Jun 9, 2015 at 10:53 PM, Pau Garcia i Quiles
<pgquiles at elpauer.org> wrote:
>
>
> 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?

>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
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>