Noosfero development cycle

This topic documents noosfero's development cycle as lead by Colivre.

Overview

An image says more than a thousand words:

Image being updated...

The process is cyclic, so we could represent it beginning with any phase, but we chose to represent it as it fits in 3 months. Here is the release schedule:

  • Day 0 ~ Day 0 + 10 weeks (roughly 2.5 months): Development
  • Day 0 + 10 weeks: RC1 Release
  • Day 0 + 11 weeks: RC2 Release (if necessary)
  • Day 0 + 12 weeks: Final Release

Phases of the cycle

Development

During this phase, the teams work on the new features. Before starting the development of the feature, the developers must create its Action Item as complete as it can get and an email must be sent to the community official development list (currently noosfero-dev@listas.softwarelivre.org) in the following format:

Subject: [feature-proposal] <feature-description>
Body:

<feature-explanation>

<link-to-action-item>

For example:

Subject: [feature-proposal] Noosfero support for video content
Body:

Hello there everyone.
I'm developing a the video kind of content for Noosfero. 
I think this is a good feature to have since video is a common content type on the web now. 
Please review my idea.

http://noosfero.org/Development/ActionItem6666

After sending this email, the community will evaluate your feature and decide whether it's good to be included on Noosfero or not. The evaluation process takes 1 week to complete by default but this time might be increased on specific situations if demanded. No news is good news, so if no one answers through the evaluation process your feature is approved and everyone is happy (=D). The method of decision will be consensus, not democracy. In case no consensus is reached after the defined time, the decision is made by the upstream. This discussion might also increase the priority of a feature over the others in case there is not enough resource (time, people, etc;) to release everything on the current release.

P.S.: the feature approval by the community does not guarantee the feature inclusion on the current release necessarily.

After it's approval, the feature must get in the development review cicle which consists of the following steps:

  1. Merge request is created with the code.
  2. Code is reviewed by the upstream.
  3. Code is good to go?
    1. Yes
      1. Go to step 4.
    2. No
      1. Merge request is rejected and the reasons are commented on the request.
      2. Developer reviews what was wrong, updates the request and reopens it.
      3. Go to step 2.
  4. Code included on the the main code. Move on with your life!

RC1 Release

The RC1 Release is the first release candidate version. After it's release no new features will be accepted on the main code. This is also the term for the release notes to be written. This version will be released on the test repository so that everyone be able to install the new version on any test server. It will also be installed on our main test repository. From this point until the Final Release (or the RC2 Release if necessary), the new features must be tested and have its bugs (which might exist but we hope doesn't!) fixed. If some feature displays any critical bug and this bug isn't fixed by the time the Final Release date come, there must be made a decision by the upstream whether to postpone the release to include the feature or to pass the feature to the next release and remove it from the main code.

Test repoisitory: deb http://staging.download.noosfero.org squeeze-test/
Alpha test server: http://alpha.colivre.coop.br/

RC2 Release

The RC2 Release is released only if there are major changes after the RC1 in order to fix any feature and those changes require new tests. It'll follow the same procedure described for the RC1.

Final Release

After the features are tested and fixed on the RC1 and RC2 the final version is released. The package is uploaded to the main repository and the cicle starts all over again.

Official repository: deb http://download.noosfero.org/debian/squeeze ./

Exceptions

If needed, there might be alpha and beta releases before the RC1 in order to test features that are too big or too dangerous. Between these alpha and beta releases and the RC1 there might be new features inclusions.

Why choose a fixed-time release strategy?

We have the following advantages:

  • all different actors involved with noosfero can plan themselves independently of the others
  • we keep a constant rhythm, which leads to:
    • we don't get relaxed enough to become inefficient.
    • we don't get stressed enough to become unhappy or unhealthy.

Add comment
You need to login to be able to comment.
 
Topic revision: r6 - 08 Oct 2013 - 20:11:39 - RodrigoSouto

irc Talk with Devs Now!

 
Translations: English
Search on Docs:
   
ActionItem Search:

Copyright © 2007-2014 by the Noosfero contributors
Colivre - Cooperativa de Tecnologias Livres