Reply New Topic
2009/11/22 6:48:42
Home away from home

Release Cycle

Get yourself a cup of coffee or some Earl Grey - this is going to be rather long.

In our wiki, we have outlined our Release Cycle. I think it is time we revise and extend this to give greater clarity and allow us to move more quickly between stages of the release.

We have been using the bug tracker to report and classify bugs and features, combining them to determine our release phase. For example, once a final release is made available, new features begin to be added, based on our roadmap. Once all, or most, of those features have been added, we release an Alpha release as a preview and proof of concept. We then refine how those features work based on feedback from other developers and the community.

Once we have them functioning pretty much the way desired, we move on to the Beta phase, where our focus turns from features to bugs. Bug classifications could be very severe (Blockers, or show stoppers), Critical - basic functions don't work, Major, Minor, or Trivial. Our current definitions in the wiki allow us to release an RC only when all known Blockers and Criticals are fixed. Our current definitions only allow us to fix new Blockers or Criticals after we have reached an RC stage.

While this is a widely accepted practice in the software community, it is rather broad and fuzzy about some things.

What this all boils down to is - How do we define Code Freeze?

When is something a new feature or enhancement to an existing feature and not a bug?

Is all code equal? To strictly apply the rule of no code changes during an RC prevents any and all changes - even modifying a language constant to clarify a label or on screen instruction is forbidden.

I definitely agree with the feature freeze stage - and this goes along with my blog post - the new features added to an upcoming release need to be focused and clearly defined before we go into developing that release and nothing more needs to be added. Once those features are in - Alpha is launched.

Now comes the tricky part - determining what parts of the code to freeze and when. I am going to suggest we need to be more precise in this area and consider the following 'types' of code for a code freeze:

* Core functions (classes, methods, arguments - API stuff)
* Language constants and documentation
* User Experience (usability)
* User Interface (design - similar to the above, but this is the look and feel, not the steps followed to complete a task)
* and, Code Performance

This is taken from reviewing the processes of other successful open source projects, trying to learn some of the best practices they are following. One thing also to note - the other projects change their commit process as they move into their final stages. Instead of committing directly to the trunk during the stabilization phase (after Beta and before Final), patches are submitted by the developers, which are then tested by the other developers before being committed to the trunk.

We may not be a big project now, but in order to be one, we need to start acting like one and the sooner, the better I'd say.

Now - your turn!


Steve Twitter: @skenow Facebook: Steve Kenow

Subject Poster Date
     Release Cycle skenow 2009/11/22 6:48:42
       Re: Release Cycle marcan 2009/11/22 7:31:40
         Re: Release Cycle skenow 2009/11/22 8:50:49
           Re: Release Cycle phoenyx 2009/11/22 12:01:22
             Re: Release Cycle marcan 2009/11/22 12:20:47
               Re: Release Cycle phoenyx 2009/11/22 12:41:00
                 Re: Release Cycle marcan 2009/11/22 13:01:42
                   Re: Release Cycle skenow 2009/11/22 15:11:33
                     Re: Release Cycle marcan 2009/11/22 17:26:01
                       Re: Release Cycle fiammybe 2009/11/23 5:06:08
                         Re: Release Cycle fiammybe 2009/11/23 5:10:20
       Re: Release Cycle phoenyx 2009/11/26 11:38:15
         Re: Release Cycle skenow 2009/11/26 19:34:00
           Re: Release Cycle phoenyx 2009/11/27 6:00:06
             Re: Release Cycle marcan 2009/11/27 19:13:13
Reply New Topic extras
 Previous Topic   Next Topic
You can view topic.
You can start a new topic.
You can reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You can post without approval.