CTools Build Process Update for 2.7

Description

Goals of the new release process:

  • Easy to create a new release

  • Easy to checkout and build a release

  • Easy to deploy a release

  • Easy to create a developer build for testing without waiting for a buildmeister to do it.

  • Easy to know exactly what is in a build and what has changed since the last build.

  • Reflect normal SVN workflow as much as possible.

Overview:
The suggested approach to source management is to create a release candidate branch designed for particular Sakai releases and to tag it when when the release is frozen. The branch would only have changes that should be in a release candidate. Any development would take place in trunk or a different branch.

  • For CTools specific projects we add a release candidate branch: branches/CTools-2.7.1C, based on previous release branch. The two primary branch repositories will be: msub/umich.edu/ctools/PATCHED/<project>/branches/RC-CTools-2.7.1. or contrib/umich/PATCHED/<project>/branches/RC-CTools-2.7.1.

  • All development not intended for a CTools release needs to be checked into trunk or JIRA-based branch of subversion

  • When we adopt a new Sakai release (e.g. 2.7.2) a new release candidate branch is created.

Environment

None

Test Plan

None
100% Done
Loading...

Activity

Beth Kirschner March 14, 2011 at 1:28 PM

Closing this since all sub-tasks & related tasks are complete. The goal of creating an easier developer build is being tracked in the wiki page mentioned above for now

David Haines March 14, 2011 at 10:01 AM

The goal of creating a build that makes a developers work easier turns out to be larger than expected and was not achieved in the work for the B and C builds. It should be created as a separate task.

Beth Kirschner February 18, 2011 at 10:49 AM

Fixed

Details

Assignee

Reporter

Components

Affects versions

Priority

Created January 4, 2011 at 2:13 PM
Updated June 7, 2012 at 8:06 AM
Resolved March 14, 2011 at 1:28 PM