Overview

• Welcome
• Features
• News
• Getting Started
  • Download
  • Install
  • Integrate
  • Use
  • Release Notes
  • Build

Build Status

DamageControl

Reference

• User Guide
• FAQ
• Developers
  • Contributing
  • IDE Configuration
  • Release Strategy
  • Uncategorized Notes

Project Info

• Mailing Lists
• Project Team
• Dependencies
• Source Repository
• Issue Tracking

Projects

• metadata provider
  • Source
  • JavaDoc
  • Clover
• dentaku-ear
  • Source
  • JavaDoc
  • Clover
• dentaku-event-cartridge
  • Source
  • JavaDoc
  • Clover
• [example-model]
  • Source
  • JavaDoc
  • Clover
• [example-web]
  • Source
  • JavaDoc
  • Clover
• foundation
  • Source
  • JavaDoc
  • Clover
• [gentaku]
  • Source
  • JavaDoc
  • Clover
• services
  • Source
  • JavaDoc
  • Clover

Feeds

• Site
• News

Release Numbering

Dentaku releases are numbered as M.m.i[-SNAPSHOT], where M is the major release, m is the minor release, and i is the incremental tag. An incremental tag release is only guaranteed to pass unit tests, and specific features that are a part of it will need to be researched through JIRA. In the BSD world, a Dentaku incremental release would be known as CURRENT.

Between incremental releases, Continuum will be used for constant build integration. The name of the release built in this manner is the number of the next release and the word SNAPSHOT. So a release before 1.3.25 but after 1.3.24 would be called 1.3.25-SNAPSHOT. There may be a handful of different binaries that have this name and a feature that was checked in between incremental tags may or may not be a part of your SNAPSHOT binary.

Incremental releases exist so that organizations may request that an incremental tag is created and set their POMs against it. Generally, this is only done in a organizational release or group development setting where the org would like to fix the feature set, such as when a contractor needs to release code to a customer. In this case, the contractor, who may have contributed code to Dentaku to fix a problem for their customer, would like to deliver to the customer without delivering SNAPSHOT builds. An incremental build will be made, the contractor can adjust the customer POMs, and the release can be made.

Release Phases

Dentaku uses a more traditional structure for the naming of releases:

• Development-phase releases are just simply numbered as above.
• Alpha-phase releases are numbered as above with the letter 'a' at the end of the version. Upon entering the alpha phase, no new features are allowed to be checked into the source base, and there must be no bugs in JIRA that are either categorized as more severe than "major". The source is "feature complete" and significantly operational.
• Beta-phase is entered when there are no bugs categorized as more severe than "minor". At this point, interfaces are locked down and all commits must be reviewed by the release team for that release. Because this is phase has a lot of overhead, it is desirable for it to be short. Users who expect to use this version for their production work should file any issues that they need resolved during this window.
• Release Candidate simply a name for a release that we expect to make into a final release nonwithstanding any new major bugs.

By upholding these phases, passive enterprise users can understand when they need to get involved to make sure that their issues are addressed, as well as get a head start with solid software as quickly as possible.

Branches

All projects like to avoid branches. But developers are a very artistic bunch, and telling them not to write new features when they are inspired to do so is basically akin to throwing away the opportunity for the feature. But new features add unacceptable risk during later release phases. Accomodating both stability and new features requires branches. Dentaku will create a branch whenever there are new features that need to be added during a release phase window, and the release team will take responsibility for merging those changes back after the release is completed.