Talk:Development/release process

Ticket processing
The following semantics are very important to ensure that long running "enhancement" branches do not diverge from the trunk, and also to ensure that developers cannnot break the trunk branch. This scenario may be particularly common if the changes did not cause a test failure on the developers platform, but did cause a failure on a different platform.


 * Automatic merge from trunk
 * A ticket branch will (optionally) receive AUTOMATIC merges from the trunk branch through the AutoBuild process. (i.e. the AutoBuild process will periodically attempt to merge changes from trunk to all ticket branches and run the tests against it.  If the tests fail, the merge will NOT be performed, and the owner of the ticket branch will receive an email that he has diverged from mainline.  Otherwise, the merge will be performed.  Therefore, the next time a user types "update" in his ticket branch workspace, he will receive:  (1) ALL updates made directly to his ticket branch and (2) any updates to the trunk which SUCCESSFULLY merged into his code without causing a test failure.
 * Nate will look into enabling this but I'm not sure it will work as desired on subversion. It will very much depend on whether automatic builds on ticket branches can be supported. Until this is resolved, coders working on ticket branches will be responsible to maintaining updates from trunk. --Dchassin 16:33, 29 November 2012 (UTC)


 * MergeToParent flag
 * When a ticket is complete, the owner of that branch may set a "mergeToParent" flag, which allows the branch to merge to parent after the tests pass and administrator approval. (If the tests fail, the merge will NEVER be performed).  Therefore, it is impossible for any developer to "break" the trunk.
 * This should be supported within the limitations imposed by subversion. Instructions need to be provided to svn/tortoise users on how to do this, including noting that this should be used until the ticket is closed. --Dchassin 16:33, 29 November 2012 (UTC)


 * AutoBuild all branches
 * The AutoBuild process will run on ANY branch that is modified (not just the trunk branch). Users will be able to see the history of test failures for any branch, and the specific commit which caused the tests to go from failing to passing.
 * Nate will look into whether there is sufficient capacity on the VM host to do this. For now coders will be responsible for building their working branches. --16:33, 29 November 2012 (UTC)


 * Style checker
 * In addition to forcing a ticket branch to pass validation tests, the ticket branch should also pass a style-checker before allowing the mergeToParent operation. There are several tools available to do basic checks for commenting standards, lines at most 85 characters, tabs vs spaces, variable naming conventions, including a 'maintainer name/email' at the top of the file, etc.
 * This seems like a nice to have. Given our budget priorities, I'll defer to a volunteer rather than assigning this to paid staff. --Dchassin 16:33, 29 November 2012 (UTC)

Test on V2.3 with Ticket 587
We tried the whole process on ticket:587 and everything worked ok. The only problem is we can't seem to lock the ticket after the merge into 2.3 is done (at least not using svn lock URL -m comment). --Dchassin 00:14, 8 December 2012 (UTC)
 * A ticket filed with SFsupport was declined as won't fix because we using the old platform. The expectation is that after we upgrade to the new platform, this problem resolve itself. --Dchassin 16:29, 19 January 2013 (UTC)

Download folder structure
The structure and file names of the gridlab-d downloads folder is confusing and inconsistent still. A little clean-up is needed and perhaps reviewing the conventions for what files go where, what they are named and which are kept is needed because the change in ticket processing makes keeping previous nightly builds unecessary. For example:


 * Four top-level folders exist at the gridlab-d downloads folder level:
 * Nightly builds : Nightly builds that have not passed the validation process
 * Old releases : Releases older than the current stable release
 * Release candidate : Nightly builds that have passed the validation process
 * Stable release : Release candidates that have survived the public review process


 * Each top-level folder has all the supported versions identified by name.
 * For nightly builds the naming convention is

gridlabd-platform-major.minor-revision.package
 * For release candidate the naming convention is

gridlabd-platform-major.minor-RCnumber.package
 * For stable releases, patches, and old releases the naming convention is

gridlabd-platform-major.minor.patch.package
 * Note : trunk is only uploaded under the nightly build folders if it compiles regardless of validation outcome

When there is no release candidate out, the release candidate folder is empty.

So for example the downloads tree might look like this when RC1 of Version 2.2 is stable and Version 2.3 is being considered.

gridlab-d +-- Nightly |  +-- gridlabd-macos-trunk-3748.dmg |  +-- gridlabd-rh5_32-trunk-3748.rpm |  +-- gridlabd-rh5_64-trunk-3748.rpm |  +-- gridlabd-source-trunk-3748.zip |  +-- gridlabd-source-trunk-3748.tar.gz |   +-- gridlabd-win32-trunk-3748.exe |  +-- gridlabd-x64-trunk-3748.exe +-- Release candidate |  +-- gridlabd-macos-2.3-RC1.dmg |  +-- gridlabd-rh5_32-2.3-RC1.rpm |  +-- gridlabd-rh5_64-2.3-RC1.rpm |  +-- gridlabd-source-2.3-RC1.zip |  +-- gridlabd-source-2.3-RC1.tar.gz |   +-- gridlabd-win32-2.3-RC1.exe |  +-- gridlabd-x64-2.3-RC1.exe +-- Stable release |  +-- gridlabd-macos-2.2.0.dmg |  +-- gridlabd-rh5_32-2.2.0.rpm |  +-- gridlabd-rh5_64-2.2.0.rpm |  +-- gridlabd-source-2.2.0.zip |  +-- gridlabd-source-2.2.0.tar.gz |   +-- gridlabd-win32-2.2.0.exe |  +-- gridlabd-x64-2.2.0.exe +-- Old releases +-- 2.0        +-- gridlabd-macos-2.0.1.dmg +-- gridlabd-rh5_32-2.0.1.rpm +-- gridlabd-rh5_64-2.0.1.rpm +-- gridlabd-source-2.0.1.zip +-- gridlabd-source-2.0.1.tar.gz        +-- gridlabd-win32-2.0.1.exe +-- gridlabd-x64-2.0.1.exe