From GridLAB-D Wiki
(Redirected from Build/release process)
Jump to: navigation, search

 Out of Date:  This page has been tagged as out of date and may contain data which does not represent current recommended use or functionality.

For information on how to build GridLAB-D on various platform, see Build page.

Development process Template:NEW30

(1)Each defect or enhancement ticket is assigned branch to embody the code that addresses it.
(2) When the branch passes validation with updates from trunk (a) and the ticket is marked fixed, the change is merged back into the trunk.
(3) If desired the ticket can be changed from defect to enhancement or from enhancement to defect, depending on whether propagation into release branches is desired:
(a) If the ticket is an enhancement it does not get merged into the releases.
(b) If the ticket is a defect it gets merged into the releases. This may break releases to don't embody the certain enhancements, so some defects can't be fixed in older releases. So be it.
(4) When a release branch reaches a RC and STABLE state it is dist built, tagged, and announced.

Code development is driven by the ticket system. In general, a branch from the trunk version is created by the ticket owner when work begins. The branch is given the name ticket/id where 'id' is the ticket number. The branch remains active as long as the ticket is open.

When the work is completed and the changes are validated on all supported platforms, the cumulative revision (included recent updates from the trunk) is posted back to the trunk. What happens next depends on the kind of ticket that originated the branch work:

Enhancement
These branches are usually long-lasting, involve potentially major changes or capability expansions, and are most likely not applied to pre-existing release branches.
Defect
These branches are usually short duration, fairly minor changes that are most likely applied to every release version they are compatible with.
Task
These are not usually branches because they don't typically involve code changes. Instead they are for things like tree maintenance, svn properties, etc.

Creating a ticket branch from trunk

host% export svnroot=https://gridlab-d.svn.sourceforge.net/svnroot/gridlab-d
host% svn copy $svnroot/trunk $svnroot/ticket/number

Checking out a ticket branch

host% mkdir -p ticket/number
host% cd ticket/number
host% svn co $svnroot/ticket/number .
... do your work here ...
host% svn commit

Updating a ticket branch

host% cd ticket/number
host% svn merge $svnroot/trunk .
... fix conflicts if any ...
host% sudo make install
host% gridlabd --validate
... fix validation errors and repeat
host% svn commit
Note
Please do not commit to trunk until your work is validated on all platforms using the ticket branch. If you need assistance with this, please contact the GridLAB-D project team.

Merging a working ticket from trunk

Important
Do not merge a working ticket into trunk until cross-platform validation is completed on the ticket branch
host% cd trunk
host% svn merge $svnroot/ticket/number
... validate ...
host% svn commit

Undoing a change

Sometimes it is necessary to undo a committed change, either because it doesn't work as expected or it was committed to the wrong branch. To remove a changeset, use the svn merge command with the -c -numberoption, where number is the changeset you wish to undo: 

host% svn merge -c -number $svnroot/branch
host% svn status
... check that the right files are unmodified ...
host% svn diff
... check that the right modifications are undone ...
host% svn commit -m "Undoing changes in changeset:number"
Note
Be very careful with the syntax, in particular noting the hyphen in front of the revision number.

Documentation

There are three kinds of documentation that you must attend to when creating or modify GridLAB-D:

Wiki pages
These are the pages located in Help:Contents, Index, etc.
Doxygen pages
These are the pages generated by the source code doxygen tags.
Troubleshooting pages
These are the pages generated by the source code troubleshooting comments.

Please see the Documentation Guide for details.

Release process

The following process is used for building and validating a release.

Nightly build

Every night a build for each platform that is supported is completed. The build is named gridlabd-platform-date-nightly. An installer extension is added that is platform dependent.

Release candidate

For each platform, if there is not current candidate release and the nightly build passes autotest, then the nightly build is renamed gridlabd-platform-major_minor-candidate-id and the availability of the candidate for that platform is announced to the news group.

Release failure

If a major, critical, or blocker reported bug for a candidate is found, the candidate is rejected and it is deleted from the server when a new candidate is released.

Release success

If a candidate survives for a few weeks without failing it is adopted as the final release for the version in question by being renamed gridlabd-platform-major_minor_0.

Release patch

After a version is released, the process continues, but only as patches named gridlabd-platform-major_minor_patch.

Platforms

Standard release platforms are

win32
Windows XP, Vista, and 7 on 32bit Intel platforms (extension exe).
x64
Windows XP, Vista, and 7 on 64bit Intel platforms (extension exe).
macosx
Mac OS X on 64-bit Intel platforms (extension dmg)
rhn
Redhat 32 and 64 bit Intel platforms (extension rpm).
source
All gnutools-capable platforms

See also

Retrieved from "https://gridlab-d.shoutwiki.com/w/index.php?title=Development/release_process&oldid=9189"