[93baf6]: / releasechecklist  Maximize  Restore  History

Download this file

197 lines (195 with data), 8.4 kB

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html; charset=UTF-8" http-equiv="content-type">
  <title>OProfile release checklist</title>
<h1><a name="OProfile_release_checklist"></a>OProfile release checklist</h1>
<span style="font-weight: bold;"><br>
Note:</span> The OProfile maintainer must give you admin privileges to
put out a release.<br>
    Create/update Release Notes for new release
      <li>Checkout or create release-notes/oprofile-&lt;new-version&gt; from 
      the oprofile-www project.  Any changelog entry that fixes a user-visible bug should be
in the new release notes unless it was not reproducible in the last release.&nbsp;
All new user-visible features should also be in the release notes.<br>
    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
    <li>Change version in configure.ac's AM_INIT_AUTOMAKE</li>
    <li>Probably want to start with a
&lt;<span style="font-style: italic;">v.r.m</span>&gt;-rc&lt;<span
 style="font-style: italic;">n</span>&gt;.&nbsp; Since this has to be
changed for
every release candidate, it's best not to commit this until the final
GA of the release.<br>
    Run <pre>make dist</pre>
    <li>If there are any ChangeLog-xxxx files that are not listed in
the EXTRA_DIST target in Makefile.am, add them to the list and <span
 style="text-decoration: underline;">commit </span>this Makefile.am
change (commit this now, otherwise you'll be making the exact same
change for every release candidate.  NOTE: ChangeLogs are no longer
used now that we've switched to git.<br>
    <li>./autogen.sh; ./configure; make dist. &nbsp; This produces a
tarball called oprofile-&lt;<span style="font-style: italic;">release</span>&gt;.tar.gz,
where "<span style="font-style: italic;">release</span>" is what
you specified in AM_INIT_AUTOMAKE.<br>
    Make a release (candidate) publicly available.
    <li>With a browser, go to the OProfile website and click on the
"SOURCEFORGE.NET" at the bottom left of the screen.&nbsp; Sign in with
your admin user ID.&nbsp; Click on "Files" tab, navigate into the "oprofile"
folder, and then click the "Add Folder"
button.  Name the folder "oprofile-&lt;release&gt;" (without the -rc&lt;<span
 style="font-style: italic;">n</span>&gt;.&nbsp;).
Start with uploading the Release Notes file you created in step 1, but
first, make a copy of it and rename it to oprofile-&lt;release&gt;_readme.
Now go into the folder you just created, click the "Add File" button to upload
the release notes "readme" file. Now click "Add File" and upload
the new oprofile-&lt;release&gt;.tar.gz file.
    <li>For each successive release candidate (and, eventually, for the GA), upload
your release tar ball the into the "oprofile-&lt;release&gt;" folder you created above.
Put a copy of the tar ball from the previous release candidate into the "oldfiles" folder;
then delete it from the folder it was in.  If the Release Notes file has changed,
delete the old one and upload the new one.
  <li>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, got
to the next step.
   <li>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.<br>
   <li>Get testing feedback from the community.&nbsp; Return to
step 1 for each new release candidate (and, eventually, for the
<em>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
    <li>Log into SourceForge with admin ID and close oprofile bugs that
have been
fixed in this release.&nbsp; <span style="font-weight: bold;">Note:</span>&nbsp;
Bugs for problems that are <span style="font-style: italic;">not</span>
reproducible in previous releases should
have been closed already.<br>
    Update freshmeat
    <li>Create an account for yourself on freshmeat (<a
and have the OProfile maintainer give you developer permissions.&nbsp;
Log in and click on the "add release" URL and follow the bouncing
ball.&nbsp; If unsure about some of the fields, look at how previous
releases were specified.<br>
    CD into the checked-out oprofile directory and open the configure.ac file.
    Specify the GA release in the AM_INIT_AUTOMAKE (i.e., &lt;<span style="font-style: italic;">v.r.m</span>&gt;).
    Now commit and push this change.
    Tag the release by running the following commands:<br>
	<pre>'git tag RELEASE_&lt;v_r_m&gt;';  e.g, 'git tag RELEASE_0_9_4'</pre>
	<pre>'git push --tags'</pre>
    Update web page release-notes/, news, download, srcdoc/, doc/
    <li>Do a 'git clone' of oprofile and
    <li>In oprofile-www, make the following updates:<br>
	<ul><li>Edit the news/index.php and
	download/index.php files to point to the new release.</li>
	<li> 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.  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.
	Now run 'sh all-events-doc.sh'.
	Finally, edit the doc/index.php file and add a link to each new events PHP file generated.
	Do a 'git diff' to verify the updates to the docs dir.</li>
	<li>Verify correctness/completeness
	of the new release-notes.  Any meaningful change seen when diffing docs/ subdir
	should be reported in the release-notes file.</li>
	Do 'git commit' of these changes.&nbsp; </li>
    <li>In oprofile, do ./autogen.sh, ./configure, and then cd into
doc/ and run 'make chunk'.&nbsp; Tar up the doc/ directory that gets created inside of
doc/.&nbsp; Then
cd into doc/srcdoc/ and run 'make'.&nbsp; Tar up the srcdoc/ directory.</li>
    Sync website to oprofile-www git
    <li>Navigate to SourceForge's site documentation (Help | Site Documentation | Complete Documentation).
Then go to "Interactive Shell Services (https://sourceforge.net/p/forge/documentation/Shell%20Service/).
See instructions there on how to do 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; CD into that directory and do a 'git
pull' to update that directory with current data from the shared repo.</li>
    <li>scp the new doc and srcdoc tar balls created in the previous
step over to SF and untar them into the git dir.</li>
    <li>Ensure that any new files you create have write access for the
group (do 'chmod g+w' if necessary).</li>
    <li>CD into the srcdoc/html directory and copy all files to the parent directory (i.e., "srcdoc").</li>
    <li>Point your browser at http://oprofile.sourceforge.net/git/ and
verify the website, documentation, etc. looks OK.</li>
    <li>Make a backup of the parent (htdocs) directory; then copy all
the stuff from the git dir into the parent dir to make it live.&nbsp;
Now use your browser to verify that the actual OProfile website looks
    Send release email.
    Change AM_INIT_AUTOMAKE in configure.ac to '&lt;<span
 style="font-style: italic;">v.r.m</span>&gt;git'; commit and push this change.