GStreamer on TI DaVinci and OMAP
Steps for Creating a Stable Release
The following steps document how to create a stable release. Some example commands are given in some places, all of which assume the release version being created is "1.00.00". This number should be replaced with the release version you are creating.
Step 0: Including Tracker Patches
Review all the open trackers that have attached patches that haven't been applied. Determine in the reviewed change is of general interest and should be part of this release. If so, apply the patch to the trunk. Note any extra test cases that need to be run to verify the patch works as expected and didn't introduce any instability or regressions. It is helpful to write down the largest tracker number so you can keep distinguish which trackers were added after the release process was started.
Step 1: Choosing the Release Number
Version numbers are chosen using a simple
When creating a new release, we typically increment the minor version number. That is, the release after 1.00.00 would be 1.01.00, then 1.02.00, etc. There are a couple of exceptions to this:
1) When there is a massive rewrite to the code or significant compatibility breaks to its interfaces, the major number will be incremented and the minor and patch numbers will be reset to "00". That is, if we completely rewrote the software after version 1.05.02, the next release would be 2.00.00.
2) If the need arises to do a bug fix in isolation of other development that has occurred on the trunk since the last release, just the required bug fixes will be made and the next release version will increment the patch version. That is, if we release 1.00.00 and then introduce a bug fixes without pulling in any new trunk development, the next release would be 1.00.01.
For this project, we do not ever expect to need to make a patch release. The normal mode for picking up bug fixes is to pull what you need from the current trunk or wait for the next trunk release.
Step 2: Freezing the Trunk
Once the release number is chosen, tag the trunk to mark the point in time that we froze for the release. The name of this tag should be "TAG_FREEZE_
Here is the svn command that would freeze the trunk for the 1.00.00 release:
svn cp https://gstreamer.ti.com/svn/gstreamer_ti/trunk https://gstreamer.ti.com/svn/gstreamer_ti/tags/TAG_FREEZE_1_00 -m"Freeze trunk for 1.00 release testing"
Next, create a release branch from the tag you just created. All bug fixes found during testing will be committed to this development branch, and once testing is done, releases will be tagged from this branch.
Here is the svn command that would create the release branch for the 1.00.00 release:
svn cp https://gstreamer.ti.com/svn/gstreamer_ti/tags/TAG_FREEZE_1_00 https://gstreamer.ti.com/svn/gstreamer_ti/branches/BRANCH_RELEASE_1_00 -m"Branch for 1.00 release"
Step 3: Testing
Check out the release branch and use for testing. While testing, make any necessary bug fixes to the release branch. Update gstreamer_ti/RELEASE_NOTES.TXT for each fix made.
svn co https://gstreamer.ti.com/svn/gstreamer_ti/branches/BRANCH_RELEASE_1_00 gst-1.00.01
The testing/gstreamer_release_testing.xls test matrix should also be updated during the test process to reflect what steps passed and failed, and unresolved failures should be entered into tracker and the spreadsheet should indicate the tracker number in the failure box.
Step 4: Update README.TXT
Verify the README.TXT documents any changes in functionality based on the patches that have been checked into the trunk since the last release.
Step 5: Update RELEASE_NOTES.TXT
Review all the tracks. For each tracker that was resolved with a patch to the trunk, document tracker as either bug fixes or new feature. For each tracker documenting a known defect that has not been resolved in this release, document appropriately.
Step 6: Update gstreamer_release_testing.xls
Always as more tests to the test matrix to cover new functionality introduced in this release. Do a regression run of all the existing tests to verify nothing got broken.
The release is now ready to be tagged.
Step 7: Tagging the Release
Tag the tested branch for a release. The name of the tag should be "TAG_RELEASE_
Here is the svn command that would create the release tag for the 1.00.00 release:
svn cp --username $USERNAME https://gstreamer.ti.com/svn/gstreamer_ti/branches/BRANCH_RELEASE_1_00 https://gstreamer.ti.com/svn/gstreamer_ti/tags/TAG_RELEASE_1_00_00 -m"Release 1.00.00"
If for some unforseen reason we want to make isolated bug fixes to this release, we would make the fix to the branch, and create a new tag for the patch release (i.e. TAG_RELEASE_1_00_01).
Step 8: Merge Release Branch Back into Trunk
Merge any bug fixes in the release branch back into the main trunk (including the release notes and the test matrix with all test results removed).
svn co --username $USERNAME https://gstreamer.ti.com/svn/gstreamer_ti/tags/TAG_RELEASE_1_02_00 gst-ti-1.02 svn co --username $USERNAME https://gstreamer.ti.com/svn/gstreamer_ti/trunk gst-ti meld gst-ti-1.02/gstreamer_ti/RELEASE_NOTES.TXT gst-ti/gstreamer_ti/RELEASE_NOTES.TXT cp gst-ti-1.02/gstreamer_ti/RELEASE_NOTES.TXT gst-ti/gstreamer_ti/RELEASE_NOTES.TXT meld gst-ti-1.02/gstreamer_ti/RELEASE_NOTES.TXT gst-ti/gstreamer_ti/RELEASE_NOTES.TXT cp gst-ti-1.02/gstreamer_ti/RELEASE_NOTES.TXT gst-ti/gstreamer_ti/RELEASE_NOTES.TXT cd gst-ti/gstreamer_ti svn ci RELEASE_NOTES.TXT -m "Release 1.02.00" cd - cp gst-ti-1.02/testing/gstreamer_release_testing.xls . oocalc gstreamer_release_testing.xls gst-ti/testing/gstreamer_release_testing.xls cp gstreamer_release_testing.xls gst-ti/testing/gstreamer_release_testing.xls cd gst-ti/testing svn ci gstreamer_release_testing.xls -m "Release 1.02.00" cd -
Step 9: Creating the Tar Balls
Change to an empty directory and checkout the script for creating the release tarballs.
Here is the svn command to checkout the release script:
Now run the release script, giving the release version as the argument. For 1.00.00, the command would be:
This will export the release tag and create both the "full" and "minimal" tar balls. The "full" version will contain the entire directory tree. The "minimal" version will contain only the plugin.
Step 10: Creating the File Repository for the Release on the Project Site
1) Go to the "Files" section, and click on "Manage Packages". This is on the lower-right of the screen after the package list.
2) For the "TIGStreamerPlugin" package, click on "Edit Releases"
3) Click on "Add Release"
4) Set the release name to the proper version number (i.e., 1.00.00).
5) Populate the release notes, which should minimally contain new features, bug fixes, and an explanation about the difference between the "full" and "minimal" tarballs.
6) Populate the "Changes" tab, which should be roughly equivalent to the contents of the release notes since the last release.
7) Set the release date to the day that the tarballs are expected to be available.
8) Attach the release test spreadsheet as a file named "release_test_results_
9) Attach the README.TXT file from the gstreamer_ti directory.
10) Attache the RELEASE_NOTES.TXT file from the gstreamer_ti directory.
11) Upload the tarballs created for the release.
12) Assocate the SVN commit that created the release tag with the release.
Step 11: Close trackers that are part of the release
Step 12: Close old abandoned trackers
Any tracker older than 6 months that hasn't been updated by its creator providing the requested information to take action on the track should be closed.
Step 13: Update gst-dmai plug-in feature support matrix
At http://gstreamer.ti.com update the matrix to reflect the features in the latest release.
Step 14: Update element documentation
Step 15: Update build instructions
Step 16: Update example pipelines
Step 17: Post news item
Post a news item announcing the new release.
|Item ID||Associated Item||Comment|
|No Associated Items Found|