T6409: New repository kdav2

[Christian Mollekopf]

cmollekopf added a comment.


  You can call it what you want, I think it's a symptom how how versioning is done in KDE (and how C++ libraries work).
  
  This is a major change resulting in a major version-bump. This always has a potential for breakage (and since it's a major version bump could also result in API changes), so it's to be expected that an underresourced project can't have that change force upon itself.
  
  This is precisely the point of major version bumps, because it *should* allow both version to coexist so some projects can continue to use what's there and works, and the rest of the world can move on. However, this is not supported by our ecosystem at all. Libraries are not coinstallable just because the so version is bumped, C++ requires complete namespacing if both libraries end up being linked into the same executable (which depending on the nature of the library is easy to end up with) and package managers cannot deal with different versions of the same package (you end up putting the version into the name anyways). KDE's solution at large seems to be to just ignore the problem and move everything forward in gridlock (you always *have* to depend on the latest), which shows itself in the rather painful major version transitions and i.e. Frameworks largely doing away with versioning all together (it's just a timestamp after all).
  
  The best solution I have found for this is to do the namespacing at repository level because that ensures that there is absolutely no misunderstanding how this works. KDav and KDav2 can move independently (of course all major work should happen in KDav2), it's possible to i.e. move KDav into frameworks as a stable version and still allow KDav2 to evolve. Packagers can easily package and distribute kdav2 and kdav, etc.
  The alternative would be to do this via a branching model, but given that there should be little to patches that apply to both (except perhaps the odd bugfix), and otherwise has a lot of risk for confusion, I'd much rather do it this way.
  
  Long story short, it will replace kdav in the long run, but don't delete that repository just yet, because they will coexist for some time.

TASK DETAIL
  https://phabricator.kde.org/T6409

To: cmollekopf
Cc: bcooksley, sysadmin, #kube, #kde_pim, cmollekopf, scarlettclark, blazquez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20170628/bc6beba4/attachment.html>