Version 4 (modified by Simon Hausmann, 15 years ago) (diff)


DRAFT -- Contributing to the API of QtWebKit -- DRAFT

If you would like to contribute new functions or classes to the API of QtWebKit, then we ask you to discuss your changes with the rest of the team first. There are certain restrictions with regards to binary and source compatibilty as well as rules for consistency in namings and concepts that require us to adjust the existing contribution process slightly for these kinds of changes.

The process

  1. Create a new bugreport in Bugzilla describing your enhancement. Please use the following template for creating the bug:
  2. Make your bug block our meta-bug for pending API enhancements for the next release: QtWebKit 4.7 Pending API This way we can easily keep track of what is left for review and by subscribing to the API meta bug we get email notifications when new APIs are submitted for review.
  3. Read the sections below about the principles and conventions we apply when designing the API.
  4. Discuss with us on IRC in #qtwebkit and on the public mailing list at
  5. After reaching an agreement, upload your patch(es) and mark them for review, using the standard process of contributiong code:
  6. The WebKit reviewers will then review the code, after the API has been approved in step 4 above.

API Style, Conventions and Principles

For QtWebKit we follow the same guidelines that are used for the Qt API. You can review the entire the style guide at

To the users of QtWebKit we promise to maintain binary and source compatibility between minor releases. We share the same policies with KDE and Qt, which are summarized on the KDE website at Another recommended read is the guide about what kind of API changes are binary compatible and what can be done to work around the imposed limitations: