Development Process
Development Process
Eclipse Che has generational advances (A.x.x), major releases with features (x.A.x), and bug fix releases (x.x.A). Each release is associated with a milestone target. We develop in two week agile iterations (Sprint) with a milestone release at the end of each sprint.
There are six roles that define responsibilities for managing our process:
-
Contributors: Anyone who participates in our GitHub forums or issues a pull request. Anyone can be a contributor. Contributors with merge rights (committers) will merge their own PRs after all reviews have completed. Contributors without merge rights will have a Maintainer merge their PR.
-
Committers: Someone with committer rights to our repositories. Any individual that gets at least two major PRs merged can be nominated by another committer to become a committer. Committers must submit at least two PRs each year to maintain their committer status. Committers also act as PR "reviewers" whose +1 consent is required for a PR to be merged.
-
Reviewers: A committer assigned to participate in a PR review. Reviewers can be asked to review any part of the product including code review, code formatting, change log, release notes, documentation, unit test verification, and the marketing material alterations that must exist when a PR is merged. Reviewers are assigned to a PR by the PR initiator, the Triager, or Maintainers. Reviewers are expected to ensure that our standards for code structure, format, and maintenance are met before offering consent.
-
Triager: A contributor assigned to apply necessary area and severity labels, assigns reviewers, and identifies the maintainer / product area for the issue. The triager is expected to review all new open issues daily.
-
Maintainers: Responsible for managing issue backlog, ensuring long term code quality for a product area, ensures that our PR process is followed, and provides technical decision making on areas where consensus does not exist. Maintainers are responsible for periodically reviewing the open PRs and issue backlog for their product area to ensure that the PR reviewer list is complete, issues are ordered properly in the backlog, and that reviewers are providing substantive reviews. Maintainers need to do the scheduling and the communication of the PR’s review - this would provide in less than 3 business days. Maintainer usually listed as a CODEOWNER of particular area and included to PR Reviewer list by default.
Maintainers:
- Server: eclipse-che/che-server CODEOWNERS
- Dashboard: eclipse-che/che-dashboard CODEOWNERS
- QE: eclipse/che CODEOWNERS
- Chectl: che-incubator/chectl CODEOWNERS
- Docs: eclipse-che/che-docs CODEOWNERS
- Plugin registry: eclipse-che/che-plugin-registry CODEOWNERS
- Devfile registry: eclipse-che/che-devfile-registry CODEOWNERS
- Che operator: eclipse-che/che-operator CODEOWNERS
- Machine exec eclipse-che/che-machine-exec CODEOWNERS
If the pull request is from a contributor without merge rights, the maintainer will perform the merge.
-
Project Leaders: Responsible for governing the project, setting the 3 month roadmap, ensuring that the development process reflects our project's values and objectives, and nominating individuals to become maintainers. Current project leader is Mario Loriedo (@l0rd).
Project leaders maintain a 3 month forward looking Roadmap which defines the themes, features and technical debt to be addressed in the time frame.
We work in two-week iterations called Sprint. We begin a Sprint on a Thursday and end on a Wednesday. We perform a milestone release (potentially shippable product) at the end of each Sprint.
At the end of each iteration, we version and release Che for community use. The project leaders will decide if a milestone release within GitHub becomes a marketing "ship" event, where we have completed the Eclipse IP process and do a broad-based marketing update with the release notes.
The work done in a sprint is captured in the Release Notes. It contains feature highlights and bugs fixed.
We make commitments for the current milestone in a two-week sprint. While working on the current sprint we pre-plan (prepare) the next milestone to have enough context for planning it. We have a planning meeting before a sprint starts with a pre-planning discussion about one week before the sprint begins. The result of these planning meeting is a issue with the kind/planning label. These are commitments to be part of the upcoming milestone assuming development is able to complete a PR merge.
A release is performed at the end of each sprint. The release procedure is automated as part of the CI/CD pipeline. We Docker to build and tag images.
During release we create a release branch from main where the release is performed. This allows us to apply bugfixes if needed, without freezing the main branch and preventing developers from merging new changes.
If a bugfix release is needed, we reuse the appropriate release branch.
We publish release notes on GitHub for each release with highlights to new & noteworthy changes.
Nightly builds are generated on daily basis and available as docker images with the tag:next.
Plans to deprecate will be outlined in issues (where possible and appropriate) for community feedback. Once feedback has been addressed deprecation schedule will be announced on che-dev mailing list. Discussed API deprecation should stay in product for at least 2 sprints before removal. Deprecation notification will be included in release notes prior to release where API is removed. In cases where the deprecation may affect white label customers, the team leads will notify PM's in advance so that those customers can be notified.