OProfile release checklist
Note: The OProfile maintainer must give you admin privileges to
put out a release.
Create/update Release Notes for new release
- Checkout or create release-notes/oprofile-<new-version> from
the oprofile-www project. Any git log entry that fixes a user-visible bug should be
in the new release notes unless it was not reproducible in the last release.
All new user-visible features should also be in the release notes.
Note: The SourceForge download site for a release will display the associated release
notes file, and due to other gunk shown on the screen, lines are broken at 72 chars,
so try to keep line length under that 72 char limit.
Check if sample data file format has changed (libop/op_sample_file.h) the since previous release. If so,
bump OPD_VERSION (in libop/op_config.h) if it hasn't already been done.
Change version to non-git and commit
Build and test a release tar file.
Make a release (candidate) publicly available.
- Change version in configure.ac's AM_INIT_AUTOMAKE
- Probably want to start with a
<v.r.m>-rc<n>. Since this has to be
every release candidate, it's best not to commit this until the final
GA of the release.
- With a browser, go to the OProfile website and click on the
"SOURCEFORGE.NET" at the bottom left of the screen. Sign in with
your admin user ID. Right-click on the "Help" link
(to open it in a new tab or window), click the "Site Documentation" link and follow the instructions
for "Using the File Manager".
- Click on the main 'oprofile' folder. For each release candidate (and, eventually, for the GA), create a
new folder, based on the release name (e.g., oprofile-0.9.5-rc1) and upload
your release tar ball into that folder. After creating the next release candidate
(or GA), cut the tar ball from the previous release candidate folder and paste it
into oldfiles; then delete the folder it was in.
- Start by uploading the new oprofile-<release>.tar.gz file.
Then upload the release notes file, but rename it to
oprofile-<release>_readme so that it's obvious to users who
browse the project files. NOTE: It may take a few minutes for the files
to become 'downloadable' (i.e., 'clickable'), and you'll need to refresh the browser to see it.
- Go to project download page on SourceForge and verify that
the new release tar ball is listed there. It will take some time for
the new release to be mirrored to all of the mirror sites. Once you
can successfully download the tar ball from a SourceForge mirror, go
to the next step.
- For release candidates, post a message to the oprofile-list
with a URL to the download page for the release you just created and
paste the Release Notes into the message. For GA release, continue
to the "Close fixed bugs" step.
- Get testing feedback from the community. Return to
step 1 for each new release candidate (and, eventually, for the
The following steps are to be done once the decision is made
to GA and you've iterated over the previous steps again for the GA
Close fixed bugs
Run the command
- Log into SourceForge with admin ID and close oprofile bugs that
fixed in this release. Note:
Bugs for problems that are not
reproducible in previous releases should
have been closed already.
'git tag RELEASE_<v_r_m>'; e.g, 'git tag RELEASE_0_9_4'
Update web page release-notes/, news, download, srcdoc/, doc/
- After committing the change to configure.ac's AM_INIT_AUTOMAKE
for the GA release, cd into the checked-out oprofile directory and run
the 'git tag' and 'git push origin <TagName>' commands.
Sync website to oprofile-www git
- Do a 'git clone' of oprofile and
- In oprofile-www, make the following updates:
Do 'git commit' and 'git push' of these changes.
- Edit the news/index.php and
download/index.php files to point to the new release.
- Regenerate events files documentation. To do this, you must first make
a temporary change in the oprofile source code -- change the value of LINE_LEN
in utils/ophelp from 99 to 999. Do a 'make install' to put this change into effect for
the actual generation of event doc. In your checked out oprofile-www dir, add new .php
files in the docs directory for any new processor type that was added since last
regeneration. Also, add a new 'do_events ...' line in the all-events-doc.sh file for each
new processor type. If any processor types were removed for this release,
then also remove the generation for its events in all-events-doc.sh. Finally,
make sure the docs/index.php is updated to reflect any new or removed processors.
Now run 'sh all-events-doc.sh' and do a 'git diff'
to verify the updates to the docs dir.
- Verify correctness/completeness
of the new release-notes. Any meaningful change seen when diffing docs/ subdir
should be reported in the release-notes file.
- In oprofile, do ./autogen.sh, ./configure, and then cd into
doc/ and run 'make chunk'. Tar up the doc/ directory that gets created inside of
cd into doc/srcdoc/ and run 'make'. Tar up the srcdoc/ directory.
Send release email
Change AM_INIT_AUTOMAKE in configure.ac '<v.r.m>git' and commit
- Navigate to SourceForge's Site Documentation (https://sourceforge.net/p/forge/documentation/Docs%20Home/).
Then click on the "Complete Documentation" link, and then click the "Interactive Shell Service" link.
See the instructions on that page on how to access SourceForge using ssh and scp.
Then ssh into SF with your admin ID and cd to oprofile's www directory
(/home/project-web/oprofile/htdocs/). There's a git dir there; do a 'git
pull' to update that directory with current data from the shared repo.
- scp the new doc and srcdoc tar balls created in the previous
step over to SF and untar them into the git dir.
- Ensure that any new files you create have write access for the
'oprofile' group (do 'chmod g+w' if necessary).
- Point your browser at http://oprofile.sourceforge.net/git/ and
verify the website, documentation, etc. looks OK.
- Make a backup of the parent (htdocs) directory; remove all
files from htdocs/docs and htdocs/srcdoc; then copy all
the stuff from the git dir into the parent htdocs dir to make it live.
Now use your browser to verify that the actual OProfile website looks