Releasing Deprecated modules and Tier 4 Definition

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140317/755e7fea/attachment.sig>