[1bbb80]: releasechecklist Maximize Restore History

Download this file

releasechecklist    193 lines (191 with data), 8.0 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.in'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.<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 "Develop" and then "File Manager" from the
"Proejct Admin" menu.  Click on the "Help" link and follow the instructions to
upload files.  Start by uploading the release file, but rename it to
oprofile-&lt;release&gt;-rel-notes so that it's obvious to users who
browse the project files. Click on the release notes file you just uploaded, and then
check the "Release note" box in "File details" -- and press "Save".  Then upload
the new oprofile-&lt;release&gt;.tar.gz file and, using the "Release notes for
this file" drop-down list box, associate this file
with the release notes file you previously uploaded.
    <li>For each successive 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.
  <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>
    Run the command <pre>'git tag RELEASE_&lt;v_r_m&gt;';  e.g, 'git tag RELEASE_0_9_4'</pre>
    <li>After committing the change to configure.in's AM_INIT_AUTOMAKE
for the GA release, cd into the checked-out oprofile directory and run
the 'git tag' command.<br>
    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' and 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 Support/Site Documentation.  Then go to
Shell services (https://sourceforge.net/apps/trac/sourceforge/wiki/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; 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
'oprofile' group (do 'chmod g+w' if necessary).</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.in '&lt;<span
 style="font-style: italic;">v.r.m</span>&gt;git' and commit