The CASA SVN branches
There are four branches:
branch is used for "active development". No warrenties. It's a place for not ready for primetime software, i.e. you're working on it and don't want the burden of responding to JIRA tickets about this or that not working because it's under active development.
branch is used to build casapy-test for internal testing. Code is moved from active to stable when the developer believes it's ready for a wider audience. We do some rudimentary testing before moving code from the active branch onto the stable branch. This branch should always build and pass a mininum set of regression tests.
branch is a staging area for releases (beta and otherwise). Code moved onto the prerelease branch has been examined for documentation and testing as well as did it fix the problem satisfy the target. On this branch we're looking to cross t's and dot i's to make sure it's ready for public consumption.
branch is what's released to the outside world. In general it will just be a copy of the prerelease branch.
In summary we go from least tested (active) to most tested (prerelease/ beta). Hope this helps.
2008 Aug 19
"devel" and "daily": Automated builds in Socorro
It might be helpful to point out explicitly that "devel" is the daily build of the active branch in Socorro.
2008 Aug 19
It used to be a a common practice that every site that development happens there is a computer that has a cron job that check out the latest in the night and run a sneeze everyday...For some times now only in Socorro this happens.
As it is not a big deal (disk usage or cpu load in the middle of the night) every developer outside of Socorro can have this happening on their desktop I suspect...hence when we refer to the "devel" or "daily" build one will have a local one available to test against.
2008 Aug 19
"nightly sneeze": Automated build at ESO
An automated attempt to build the latest version of CASA from the active branch of the repository under RHEL 5.3 is run every morning at 5:00 h UTC at ESO. The resulting "casapy" is briefly started to test that it executes without missing libraries. This includes a complete update and rebuild of the casacore libraries.
Since 20 Aug 09 the report from this is posted at http://www.eso.org/~dpetry/nightly-sneeze.log
. Look in the last line for the word "PASSED" to see if everything is OK.
On 16 Dec 09, a second automated build was added on a standard ALMA 64bit RHEL 5.3 machine. The report is posted at http://www.eso.org/~dpetry/nightly-sneeze-64bit.log
Please mail mailto:email@example.com
if you would like to receive automated daily emails about the outcome of the automated builds.
"More explanation of the branches"
The active branch; Here is where you can check in code and see how it plays with the rest of the system. In general the active branch is not for end-users, but for developers to test ideas without the worry of getting inundated by JIRA tickets. Once the developer believes it is ready for internal testing they mark the code "Ready for Release" and then it will be migrated on to the stable branch.
The stable branch; The integrator merges the code marked "Ready for Release" onto the stable branch. Only a minimal set of tests are run at this step, the idea being we guarantee that the system will build and successfully run a standard set of tests. The intention is to get internal testers ready access to new development in a stable environment reasonably quickly. During a development cycle merges from active to stable should happen once or twice a week. As we approach releases the merges happen more frequently, i.e. daily. JIRA tickets for bugs reported by internal testers should be issued against builds on this branch. More comprehensive testing is run on the stable branch.
The prerelease branch; As release time approaches, code from the stable branch is merged on to the prerelease branch after all comprehensive verification tests pass. JIRA tickets are checked that what was claimed to have been fixed was fixed. We should use this branch for selected external testing.
The release branch; Once all show stopper bugs/tasks have been addressed (either by fixing them or declaring them not show stoppers) and we have a clean run of the comprehensive tests, the prerelease branch is merged (well actually copied) on to the release branch and tagged.
A Review of Some Subversion Concepts
2009 Mar 23