PayPal - The safer, easier way to pay online!

[ Previous | TOC | Next ]

Preamble

NOTE: The official repository is available in a later version. If you want to share your work or get support for your company please contact us directly.

Featured projects are listed at a special catalog. You may referr to this catalog and you may get some special services for free if you match the featured projects requirement.

Rules

  • Clean website URL: You must either set a manual URL at the xworlds website or you must set a valid URL in the POM where the "mvn site" is uploaded to. This must be a valid URL presenting your project. For a project made of multiple modules you may set a URL for your groupId organization.
  • Issue management/ support: Set the issue management in the POM. Users must be able to contact your support. If you provide a trac, a mailing list or something else is not that important for us as long as every user is able to contact your team.
  • Team information: Set valid information on your official team members. At least one team member must be present on the xworlds and have an account there.
  • Extended project information: Within the project pom or xworlds website you must set additional project information, such as the categories the project will be listed.
  • Extended validation: You must follow some code conventions and install the proper plugins. Either use the org.phpmaven:php-featured-parent-pom as the pom parent or configure the our build plugin to use the extended validation for featured projects.
  • Code style: The code style must be checked by checkstyle. No checkstyle validation means no featured project. You may choose your own checkstyle rule.
  • Site generation: The module must always generate a valid "mvn site" including checkstyle report, api documentation, PHPUnit reports.
  • Unit testing: The project must provide test cases. There are several test frameworks, such as PHPUnit, JSUnit, Selenium.
  • Project type: The project types introduced in PHP-Maven 2.1 must be valid. Unknown project types are not allowed for featured projects. Any extended validation for class file organization must be successful.
  • Documentation: You must provide good documentation There are several validations on api documents.
  • API/IMPL: If you choose to build projects with public API you may split your project into an API and an implementation module. You will have to set the proper type. This will cause the implementation to not be listed as a single module. And it will result in deactivation of some validations on the implementation (for example the need of document every file and private class member).

Versioning and activity

  • Pre-release versions: All versions below 1.0.0 are meant to be unstable alpha versions. You must not reach the beta stage before reaching version number 1.0.0. The first beta will be 1.0.0-beta-1.
  • Unstable versions: Unstable or development versions are always SNAPSHOTS. Version 1.4.5-SNAPSHOT is meant to be an unstable development version meant to reach release version 1.4.5 one day.
  • Alpha/Beta/RC version: You may release multiple alpha versions (f.e. 1.3.4-alpha-1 and 1.3.4-alpha-2) before releasing. You may release multiple beta versions (f.e. 1.3.4-beta-1 and 1.3.4-beta-2). You may use release candidates (f.e. 1.3.4-RC-1 and 1.3.4-RC-2)
  • Beta/RC before major release: To increment the major version (f.e. 2.0.0, 3.0.0) you must always provide at least one beta or release candidate version for this new major version.
  • Alpha/Beta/RC before minor release: To increment the minor version (f.e. 2.4.0, 3.2.0) you must always provide at least one alpha, beta or release candidate version for this new major version.
  • Review before reaching 1.0.0: Before reaching Version 1.0.0 there will be a project review. At this review there will be a team of at least three members looking at your project. At least one member is from your project and at least one member is from xworlds. The third member should be an active community member. This review is meant for analyzing your project and the projects content before reaching a 1.0.0 release.
  • Activity: Your team must at least be active once every 3 months. Either click on the xworlds homepage that there is no need for new releases or deploy any new release. If you use our versioning service a single commit is registered as activity too.
  • No unstable dependency: Release candidates and releases must not depend on unstable/ alpha/ beta versions of other modules.
  • Community release cycle: You may organize your release cycle to be the same than our community release cycle. We will have 3 releases per year with proper timelines for reaching alpha/beta/release candidate versions. You may sign to a community release at the xworlds website. To sign up you must provide a development and feature plan as well as a version branch. We will devide two groups of modules: Framework modules (those being very central for many other modules) and normal modules. Framework modules must reach at least a beta stage very early.
  • API freeze: Those classes and scripts marked to be the API of your project must be freezed as soon as you reach a RC version. Breaking this rule requires you to enter a reason at xWorlds homepage (for example referr to a hotfix caused by a bug). API must not be changed within fixlevel versions.

Why these rules?

The answer is simple: Featured projects are always meant to be of good quality. By using these rules there is a good chance that your project is good. Every user that depends on featured projects should be sure that these projects are stable and that they are getting good support.

[ Previous | TOC | Next ]