[Kde-pim] Focus on stability, LTS branch, transition to frameworks

Tue Apr 15 12:20:47 BST 2014

On Friday 11 April 2014 17.49:02 John Layt wrote:
> We have 3 main components in KDEPIM:
> 
> * akonadi
> * pimlibs
> * apps
> 
> Akonadi doesn't use Frameworks and is already Qt5-ready, so doesn't need
> any further thought, it can carry-on getting new features as needed.
> 
> For pimlibs and apps we have two possible strategies:
> 
> 1) Split Frameworks and Application releases.  At some point put kdepimlibs
> into freeze and start working on the Frameworks split.  Once the split is
> done and stabilised enough for a beta release (say after 6-9 months) then
> start thinking about porting the apps and getting feedback from that
> process.
> 
> 2) Simultaneous Frameworks and Application releases.  Wait for a convenient
> point-in-time, say after KF5.0 and KDE 4.14 releases, and then try to
> switch everything over at once.
> 
> Option 2 sounds like one big mess to me, it's not really an option is it?
> 
> :-)  So it really is just a decision on when pimlibs gets frozen, or
> 
> semi-frozen, or whatever.
> 
> Let's look at the future release dates, assuming 6 months on from the 4.13
> release:
> 
> 2014-06-01 KF 5.0 Release
> 2014-08-26 KDE 4.14 Feature Freeze?
> 2014-10-16 KDE 4.14 Release?
> 2014-12-01 KF 5.1 Release?
> 
> kdepimlibs has already had a lot of Frameworks work done preparing it, some
> in current master and some in a frameworks branch, mostly by Steven Kelly,
> and the road map is fairly clear.  We also have external users like Plasma
> clamouring for some of the libs to use in a Plasma 2014.12 timeframe
> (calendar, holidays, etc).  There really is probably not that much work
> required to split them, and having a Tech Preview out within 3 months of
> starting work is not impossible, with a cleaned-up API and split ready for
> beta perhaps 3 months after that.  Some libs could even be moved to KF5
> earlier than others, e.g. KHolidays could easily be split and cleaned-up in
> time for KF5.1 and Plasma 2014.12, while other more complex libraries wait
> for KF5.2 or later.
> 
> kdepim apps really shouldn't be thinking about a Frameworks port until the
> pimlibs have at least reached Tech Preview or Beta stage, so not for at
> least another 3-6 months, which comfortably leaves time for new features
> and major improvements in 4.14.  Given the Baloo changes, and the known
> issues still with maildir, I believe we need at least 4.14 to provide a
> stable solution for users for the 12 months or more while the Frameworks
> version is ported.
> 
> Even if Laurent is putting new features into pimlibs during 4.14, they
> would all be in place before the earliest possible split of pimlibs would
> make merging difficult, so I see little obstacle to his doing that.  Once
> the split happens though then managing merges becomes a major pain, so
> that's the pimlibs4 hard-feature-freeze point.
> 
> So, if we were to target a non-split Tech Preview after the 4.14 feature
> freeze (2014-09 or 2014-10), that would allow Laurent a 4.14 release before
> switching his attention to stabilising PIM Frameworks, and those interested
> in frameworks can get to work once 4.13 is released.  The simpler pimlibs
> that Plasma wants like KHolidays could target a split and inclusion in KF
> 5.1, with the rest of pimlibs a first split beta around 2014-12 with a
> final release with KF 5.2 (2015-06?), and Applications switching to
> Frameworks development using the beta in January 2015.
> 
> Thoughts?

Thanks John for the detailed write-up. Let me put that into my own words:

We'll continue development in master and eventually release a 4.14.

Meanwhile frameworks is being prepared for kdepimlibs, and as I understand it 
is not a large problem to merge master into frameworks, and it is therefore 
not problematic to continue development on master and have frameworks as side 
project.

Once we split the repositories the merges do become problematic, so at this 
point we should "freeze" kdepimlibs, respectively  declare it stable and it 
should be clear that everything that is committed to current kdepimlibs needs 
to be manually ported to frameworks (and should therefore be avoided).

So at this point (once the split is done) the frameworks repositories are 
current development HEAD, and should therefore be treated as such, meaning 
developers should work in the frameworks repositories. It should IMO be up 
to each developer whether they also want to add their bugfixes to the old 
kdepimlibs repo that contains the current stable branch.

Once kdepimlibs is split we can make all the BIC changes and eventually 
release it, which then enables all kdepim applications to be ported to 
frameworks.

If I put that into a timeline (without dates for now):
** preparations in the frameworks branch
** development in master
* [MILESTONE] frameworks repository split, kdepimlibs declared stable => 
nothing will be merged from kdepimlibs to frameworks, only bugfixes should be 
applied to kdepimlibs.
** BIC changes in frameworks, preparation for release
* [MILESTONE] kdepimlibs frameworks are released => enters binary 
compatibility mode (actually there is a milestone for each framework since 
they can be released individually)
* [MILESTONE] kdepim + kdepim-runtime repository split, old repositories enter 
maintenance mode
** applications are ported
* [MILESTONE] frameworks release of kdepim applications

Yes?

Cheers,
Christian

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/