Site Tools


This is an old revision of the document!

(Proposed) Feature, Branch and Release Process


IoTivity is adopting a process to marshal contributions of any size into the project. This document will walk you through the process of suggesting a feature, design with review, implementation with review, acceptance and scheduling for release. There are milestones for your feature as well as milestones for release that are covered on this page.

Feature Milestones

Features come in many sizes and implications. The requirements for each are a little different. Trivial features are those that only affect a handful of files, easily expressed in a very short paragraph and have limited impact on the larger body of code. Minor and major features are larger, require a design and design review and may impact the entire stack operation. The process for each is covered here.

Where does it start?

It starts with an idea. A potential contributor should start by bringing their feature to the iotivity-dev mailing list. In this forum, the idea can be vetted and the size and scope can be determined. If the feature is trivial, such as adding a new property to a resource, it may be listed (see below). If more detailed discussion is needed, the contributor should capture the feature as a design document or design notes on the wiki so that it can go under review.

TODO: Add link to an example

Feature (Design) under Review

After the design is posted to the wiki and the posting has been announced on the mailing list, it is considered under review. At this time discussion should continue on the mailing list and the author should continue to edit the design on the wiki based on feedback. Once all comments have been addressed, the feature may be listed (see below)

TODO: Need to define time under review. Silent consent allowed?

Feature Listing

Listing your feature just means that it is tracked in Jira. When ready, the contributor or requester of the feature should create a Jira ticket (enhancement) to track the feature. Jira will be used to track who is working on it and to provide status. Jira allows “child” tickets to allow reporting of progress. Using this feature is highly encouraged. If there is an associated design document, it is recommended that the URI to the design document to be included on the Jira ticket AND that the design document refer to the Jira ticket(s).

If the feature requester is also going to be the contributor, it is recommended that they assign the Jira ticket to themselves.

TODO: Add link to Jira site.

Feature in Progress

Once there is a Jira ticket and a contributor is ready to implement, the contributor should request a feature branch from the domain maintainer. When requesting, be sure to provide the Jira ticket number so the maintainer can determine whether the feature is ready (ie. design covered the feature and has been reviewed if needed). Again, it is best practice to note the branch name on the Jira ticket as well as post progress to the Jira ticket comments.

Feature Complete

To be feature complete, a contributor must meet the following criteria:

  • Code complete
  • Unit tests
  • Sample application written, if needed
  • Validated in build environment
  • Testing complete
  • Documentation updated, if needed

At this point, the contributor may push to gerrit for community review. The contributor should be sure the invite the domain maintainer and any other members that may have participated in the design discussions. After addressing all of the concerns of the maintainer, the maintainer will give the review a +2 and submit the code.

TODO: Talk about the merge process from the feature branch to the master branch.

Release Milestones

The IoTivity Steering Group has agreed to two types of releases. The first and most common is the minor release. A minor release will increase the minor version or revision version numbers. For instance, consider the following:

  • 0.9.0 =⇒ 0.9.1 (Revision, minor release)
  • 0.9.6 =⇒ 0.10.0 (Minor version, minor release)
  • 0.9.7 =⇒ 1.0.0 (Major version, major release)

The goal and process for each of these is different. Each is discussed below.

Minor Releases

The goal of the minor release is to provide timely updates (currently on a two month cadence) to IoTivity including fixes and any available features to date. Generally, these do not align to standard changes and should be compatible over the air but may contain some changes to the programming APIs. The following sections describes the milestones for a minor release including criteria to reach the milestone and the tasks, roles and responsibilities that the milestone triggers..

Release Feature Freeze

The feature freeze date is the cut-off date for features to make it into the next release. For a feature to be accepted into a release, it must be feature complete, reviewed and accepted into the master branch before the cut-off date. Any feature that is pushed into master AFTER the cut-off date will naturally slip to the next release.

At feature freeze, the following steps will be taken:

  1. A release branch will be created from master by one of the maintainers.
    1. The branch name will follow the release name ie. 0.9.1-dev
    2. A tag will be created immediately marking the release candidate 0.9.1-RC1
    3. The branch and tag will be announce on the iotivity-dev list
  2. Test engineering will begin system testing on the release
  3. Release management will start writing release notes based on the features which made the release
  4. Maintainers will only accept bug fixes into the release branch.
    1. TODO: It has been recommended by Erich that general bug fixes should be delivered to master, verified there and cherry-picked to the release branch. They may be exceptions where a fix is only a work around for a bigger issue. In this case, it may make sense that a fix would only go to the release branch.

Release Quality Report

About 5-7 days later, depending on the size of the release, test engineering will provide a status report on the quality of the release. Base on the results, a final date will be announce for the release to give time for any fixes for the release branch.

At feature freeze, the following steps will be taken:

  1. A release branch will be created from master by one of the maintainers.
    1. The branch name will follow the release name ie. 0.9.1-dev
    2. A tag will be created immediately marking the release candidate 0.9.1-RC1
    3. The branch and tag will be announce on the iotivity-dev list

Code Freeze

Once all prevailing issues have been addressed. The release code is considered frozen.


Release - To reach release the following release criteria must be met….
Once, the release milestone is reached the following actions will be take:
tar ball will be created by the <enter role here>, documentation update by
the <enter role here>,…

Major Releases

Regarding Defects

iotivity_features_branches_and_release_process.1433449105.txt.gz · Last modified: 2015/06/04 20:18 by pclanksw