Export to GitHub

gmaps-utility-library-dev - ReleaseProcess.wiki

Introduction

This is the release process for pushing stuff out to the release library. Anyone can make the releases, but if you do not feel comfortable with SVN or SVN tags, please email the list and request that a release engineer push it out. The pre-release and post-release process is common across all releases, but there are slightly different steps for version 1.0 of a library versus later versions.

Pre-Release Requirements

  1. Do an svn update on local gmaps-utility-library-dev
  2. Check the library meets the release requirements:
    • examples/:
      • Each example should have an API key for http://googlecode.com.
      • Each example should work in our supported browsers (IE6+,FF2+,Chrome,Safari3+).
      • Each example should follow our conventions. See JavascriptCodingConventions.
      • There should be an example that covers each API option/function (a wizard can be a good way to do this, for a complex constructor).
      • The examples should have descriptive, simple filenames.
      • Each example should have a script tag and HTML links that allow for easy checking of the packed JS. See this example.
      • Examples should not reference relative paths whose relative location will change once they're put in /tags/. The only permissible relative paths are those underneath the library's own folder.
    • docs/:
      • reference.html:
      • The reference should be autogenerated using JSDoc and the "all-docs" ant target. See UsingUtilities.
      • The JSDoc comments should be easily readable English. If you are not a native English speaker, ask another developer to revise them for you.
      • examples.html:
      • Every example should be referenced from this doc, with atleast a few sentences of description.
      • Make sure the code snippets are all up-to-date, if you changed any of the example code.
    • src/:
      • The code should follow our conventions. See JavascriptCodingConventions.
      • There should be no use of undocumented API options or methods, and no hacking of the DOM. Basically, the library should be future-proof.
      • There should be an up-to-date packed version of the code, generated using the "all-pack" ant target. See UsingUtilities.
  3. If you made any changes while checking that the requirements were met, commit those changes.
  4. Email the group and maps-api-support@google.com to tell them that the library is nearly ready to release. Ask them to report on any issues found, and ask for approval to release.

Pushing out version 1.0

  1. Make sure all pre-release requirements are met (above).
  2. Make sure you have the /tags/ directory checked out - the default source checkout only gets the /trunk/. If you need to, do a new checkout of /svn/ now. svn checkout https://gmaps-utility-library-dev.googlecode.com/svn/ gmaps-utility-library-dev-release --username YOUR.USERNAME
  3. Do an svn update in your local repository svn update
  4. Create a folder for the library under /tags/, add it, and commit it. mkdir tags/labeledmarker svn add tags/labeledmarker svn commit tags/labeledmarker
  5. Use svn copy to create the new tag from the trunk svn copy https://gmaps-utility-library-dev.googlecode.com/svn/trunk/labeledmarker/ https://gmaps-utility-library-dev.googlecode.com/svn/tags/labeledmarker/1.0 -m "Tagging 1.0 release of LabeledMarker"
  6. Test each of the files in http://gmaps-utility-library-dev.googlecode.com/svn/tags/library/1.0/examples to make sure API keys work, mime-types are correct, etc. Browser bugs should be worked out by now.
  7. Update release_notes.txt in the /library/ folder to indicate changes and changed issues. (TODO: Decide if that is best place for changelogs).
  8. Proceed to post-release festivities (below).

Pushing out later versions

  1. Make sure all pre-release requirements are met (above).
  2. Verify that examples exist that test all the introduced changes since last release. You can see what revision a tag represents by clicking "diff" on the revision that created the tag. The revision will be on the left side. For example:
  3. Make sure you have the /tags/ directory checked out - the default source checkout only gets the /trunk/. If you need to, do a new checkout of /svn/ now. svn checkout https://gmaps-utility-library-dev.googlecode.com/svn/ gmaps-utility-library-dev-release --username YOUR.USERNAME
  4. Do an svn update in your local repository svn update
  5. Change version number in the comments of the .js file to reflect new version number.
  6. Do an svn copy to a tagged folder for the release version. If needed, you can specify a revision to do it from with "-r NNN". svn copy trunk/labeledmarker tags/labeledmarker/N.N
  7. Run svn propset on all files (for HTML/CSS). This makes sure they show up in the browser: find . -name '*.html' | xargs svn propset svn:mime-type text/html find . -name '*.css' | xargs svn propset svn:mime-type text/css find . -name '*.js' | xargs svn propset svn:mime-type text/javascript find . -name '*.xml' | xargs svn propset svn:mime-type text/xml find . -name '*.png' | xargs svn propset svn:mime-type image/png find . -name '*.gif' | xargs svn propset svn:mime-type image/gif find . -name '*.jpg' | xargs svn propset svn:mime-type image/jpeg
  8. Run a svn diff between the folder for the last version with the folder for the new version. Make sure you recognize all changes. svn diff tags/labeledmarker/1.1 tags/labeledmarker/1.2 //or, if that fails, diff the JS files diff tags/1.1/src/labeledmarker.js tags/1.2/src/labeledmarker.js
  9. Test each of the files in release/examples to make sure they work as intended in the supported browsers.
  10. Run svn commit on the new folder. In the message, reference which revisions this release represents. svn commit -m "Adding LabeledMarker v1.2. Represents versions 589 through 631 See http://code.google.com/p/gmaps-utility-library-dev/source/list?path=/trunk/labeledmarker/" tags/labeledmarker/1.2/
  11. Test each of the files in http://gmaps-utility-library-dev.googlecode.com/svn/tags/library/NN/examples to make sure API keys work, mime-types are correct, etc. Browser bugs should be worked out by now.
  12. Update release_notes.txt in the /library/ folder to indicate changes and changed issues. (TODO: Decide if that is best place for changelogs).
  13. Proceed to post-release festivities (below).

Post-Release Festivities

  1. Email the mailing list about the new version.
  2. Add the library to the front page to the Libraries wiki.
  3. Go to Administer->Issues and add a label for your class (e.g. Class-KeyDragZoom).
  4. Add examples to the Google Maps API demo gallery.
  5. Publish a blog post announcing the new library. See BlogPostGuidelines.