On Saturday, March 15, 2014 16:59:54 Kevin Ottens wrote:
>  we would be releasing 5.0 with modules which would be immediately 
>  deprecated.

the modules that i am aware of include:

* kde4support
* khtml
* kjs
* kjsembed
* krunner

there are a few others that are imho borderline cases (kmediaplayer as one 
example) but the above are the clear cases.

as a side note, could we also rename kde4support to kdelibs4support? we've 
spent a lot of time and effort to stamp out the (broken) "kde4" naming.

> 2) Release the deprecated content as a separate product

this is the best option imho because:

* it keeps "Frameworks" clear in scope and focus: the set of recommended and 
actively developed APIs. this should be useful for app developers and 
packagers alike.

* it allows dropping the deprecated modules at a future time without worrying 
about what it means for "Frameworks" or how to communicate the change clearly

* it sets a clear precedent for KF6 as to how to handle frameworks that become 
deprecated during KF5's life

> 3) Roll all the deprecated modules into KDE4Support

-1, for the reasons dfaure noted.

> 4) Announce the deprecated modules will only be released three times

+1

after those releases, the core team would no longer need to:

* manage bug reports filed against those modules
* coordinate the release of those modules (which at a minimum means building 
and testing prior to release)

public communication will be clearer; instead of a vague "deprecated, 
eventually dropped" there is a clear horizon to communicate

developers will have a soft deadline for when they should want to complete 
porting away from these modules. it's only a soft deadline as the code will 
obviously still exist and someone could pick up maintenance. we all know that 
things tend to happen faster / more reliably when there is deadline.

if there is interest in maintaining the modules past that date, those 
interested can take on the effort after this point.

-- 
Aaron J. Seigo

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to