Login | Register
My pages Projects Community openCollabNet

argouml
Wiki: Diff for "Making a release"

Edit this page | Links to this page | Page information | Attachments | Refresh page

 

Differences between revisions 8 and 24 (spanning 17 versions)

Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
The purpose of this is to simplify the procedure for the person actually doing the release work, and to make sure that everything is done in the exact same way every time without anything being forgotten. The purpose of this description is to simplify the procedure for the person actually doing the release work, and to make sure that everything is done in the exact same way every time without anything being forgotten.
Line 9: Line 9:
 * Subversion write access to the argouml projects (to create the releases branch/tag). The projects involved are specified in the file argoumlinstaller/build-release.sh.  * Subversion write access to the argouml projects (to create the releases branch/tag). The projects involved are specified in the file '''argoumlinstaller/build-release.sh'''.
Line 11: Line 11:
 * A machine with 3GB of disk to use for this purpose (September 2006).  * A machine with 10GB of disk to use for this purpose (October 2009. In September 2006 it was 3GB).
Line 21: Line 21:
 . Note that the argouml-downloads checkout is large (over 2 GB) and will take a considerable time to check out so you'd better do this in advance.  . Note that the '''argouml-downloads''' checkout is large (over 6 GB download) and will take a considerable time to check out so you'd better do this in advance.
 * The '''!JimiProClasses.zip''' downloaded and copied into '''argoumlinstaller/build'''.
Line 23: Line 24:
 . Run the command '''keytool -list -v''' and give the keystore password '''secret'''. You should have a key named argouml that is valid several months in the future.  . Run the command {{{keytool -list -v}}} and give the keystore password '''secret'''. You should have a key named argouml that is valid several months in the future.
Line 26: Line 27:
 . A key is generated with the command '''keytool -genkey -alias argouml -storepass secret'''.  . A key is generated with the command {{{keytool -genkey -alias argouml -storepass secret}}}.
Line 33: Line 34:
 . If there are any new projects to be included in the release, add them to the list of projects in argoumlinstaller/build-release.sh. You also need to create the releases-directory at the top of the SVN repository.  . If there are any new projects to be included in the release, add them to the list of projects in '''argoumlinstaller/build-release.sh'''. You also need to create the '''releases'''-directory at the top of the SVN repository.
Line 35: Line 36:
 . This is done using the command ./build-release.sh -tc in the argoumlinstaller project and giving the release name.  . This is done using the command {{{./build-release.sh -tc}}} in the argoumlinstaller project and giving the release name.
Line 38: Line 39:
 3. Set the argo.core.version to not include the "PRE-" part and commit the files.
 . This is done in the default.properties-file in build/VERSION_GIVEN_VERSION/argouml/src/argouml-app and in the build.xml-file in build/VERSION_GIVEN_VERSION/argouml/documentation.
 3. Set the version to not include the "PRE-" part and commit the files.
 . This is done in the '''!ArgoVersion.java'''-file in '''build/VERSION_''GIVEN_VERSION''/argouml/src/argouml-app/src/org/argouml/application''' and in the '''build.xml'''-file in '''build/VERSION_''GIVEN_VERSION''/argouml-documentation'''.
Line 41: Line 42:
 . This is done using the command '''./build-release.sh -bs'''  . This is done using the command {{{./build-release.sh -bs}}}
Line 48: Line 49:
  a. Make sure that the upcoming releases have target milestones created for them. This needs to be done for all components that has the same release scheme. Also see that the numbering is the same in all components and that it is in the correct chronological order except for the not yet done releases that come before the already completed.   a. Make sure that the upcoming releases have target milestones created for them[[FootNote(This needs to be done for all components that has the same release scheme. This is the main reason we have everything that is released in the same component.)]]. Also see that the numbering is the same in all components and that it is in the correct chronological order except for the not yet done releases that come before the already completed.
Line 58: Line 59:
  a. For stable releases, decide on when RESOLVED or VERIFIED issues are closed.   a. For stable releases, decide on when FIXED issues that are RESOLVED or VERIFIED will be closed.
Line 85: Line 86:
  . This is done by the command ./official.sh.   . This is done by the command {{{./official.sh}}}.
Line 87: Line 88:
  . These files are located in the svn/argouml-downloads/www/jws-directory.
  a. Update the index files for the downloads project to point out the new release. The index.html is for the stable releases, the devrel.html for all releases.
  . They should point out the release at /argouml-RELEASENAME/, the Java web start file at /jws/argouml-RELEASENAME.jnlp.
  . These files are located in the '''argouml-downloads/www/jws'''-directory.
  a. Update the index files for the downloads project to point out the new release. The '''index.html''' is for the stable releases, the '''devrel.html''' for all releases.
  . They should point out the release at '''/argouml-''RELEASENAME''/''', the Java web start file at '''/jws/argouml-''RELEASENAME''.jnlp'''.
Line 102: Line 103:
  -m'Installer used for GIVEN_VERSION   -m'Installer used for GIVEN_VERSION.'
Line 105: Line 106:
 . This is done by updating the PRE-VERSION in the trunk version of the files mentioned in 3

=== More release-related things for stable releases ===
For stable releases there are some extra things done to publish more information since the stable releases are used as reference for future work.

Do the following:
 1. Fix the javadoc version.
 1. Fix the ArgoUML documentation.
 1. Create Project Set Files that checks out Eclipse projects from the branch. (argouml-gen/psf/gen-psf-files.sh)
 . This is done by updating the PRE-''VERSION'' in the trunk version of the files mentioned in 3
Line 116: Line 109:
=== The release did not work ===
/!\ Warning: This description is not yet updated to fit the subversion set up for ArgoUML.

This shouldn't happen! This really shouldn't happen!

The reason that this has happened is that one of the developers has made a mistake. You now must decide a way forward.

==== Fix the problem yourself. ====

If the problem is obvious to you and you can fix it quickly, do so. This is done by doing the following:

 * Make the release tag into a branch
 * Check out that branch
 * Fix the problem in your checked out copy
 * Commit the problem to the branch
 * Continue the build process
 . This is done by restarting the build dist-release-command and from that point on working in the branch instead of at the tag.
 * Explain to the culprit what mistakes he has made and how to fix it.
 . It is now his responsibility to make sure that the problem will not appear in the next version. He can do this either by merging in your fix or by fixing the problem in some other way.
 . At this point an in-detail description of how poor programming skills the culprit has and how ugly his mother is, is probably in place but please keep it constructive! Remember, you might be mistaken when you guess who the responsible is.

==== Delay the release waiting for someone to fix the problem. ====

Create the branch as described in the previous section on how to “Fix the problem yourself.”. Then tell the culprit and everyone on the developer list what the problem is and that it is to be fixed in the release branch a.s.a.p.

Monitor the changes made to the branch to verify that no one commits anything else but the solutions to the problems.

When you get notified that it is completed, update your checked out copy and continue the release work.
The are some extra considerations when ["/Making a Stable release"].

The purpose of this description is to simplify the procedure for the person actually doing the release work, and to make sure that everything is done in the exact same way every time without anything being forgotten.

The scripts involved have been developed and are mostly run on a Cygwin system. They will hopefully work on any UNIX system but most likely they will need some adjustments.

The scripts and tools used specifically for the build are maintained in the argoumlinstaller project. From the argouml project the files argouml/build.xml and other build.xml files are reused.

Prerequisites (what you need to be able to do this):

  • Subversion write access to the argouml projects (to create the releases branch/tag). The projects involved are specified in the file argoumlinstaller/build-release.sh.

  • Subversion write access to the argouml-downloads project (to upload the result).
  • A machine with 10GB of disk to use for this purpose (October 2009. In September 2006 it was 3GB).
  • This is probably the machine you use for your development if you are an argouml developer.
  • The machine needs Internet access (it is not a small download and upload so at least 128KB Internet connection to keep the time reasonable < 2 hours), the correct version of Java installed (should be a JDK for Java5), SVN installed, Unix or Cygwin to be able to run the scripts.

  • The argoumlinstaller and argouml-downloads projects checked out alongside each other.
  • If this is not in place from a previous release this is done using the commands
  • cd wherever
    svn co http://argoumlinstaller.tigris.org/svn/argoumlinstaller/trunk argoumlinstaller
    svn co http://argouml-downloads.tigris.org/svn/argouml-downloads/trunk argouml-downloads
    
  • Note that the argouml-downloads checkout is large (over 6 GB download) and will take a considerable time to check out so you'd better do this in advance.

  • The JimiProClasses.zip downloaded and copied into argoumlinstaller/build.

  • You have generated a key to sign the jar files (for Java Web Start).
  • Run the command keytool -list -v and give the keystore password secret. You should have a key named argouml that is valid several months in the future.

  • This is to make sure that you have a valid key for the purpose of signing the jar files.
  • Since the ArgoUML project and the Tigris organization are loose organizations we cannot buy a "real" key. The keys we use are the unsigned keys that can be generated by anyone using the keytool provided with Java.
  • A key is generated with the command keytool -genkey -alias argouml -storepass secret.

  • By default these keys have a validity of just three (3) months but by giving the -validity days the validity can be extended.
  • Don't forget to upload your new key to the Downloads area. This is for those who want to see the key on the site separately.

Here are the steps to be done when one actually does a release:

  1. Check for new projects.
  2. If there are any new projects to be included in the release, add them to the list of projects in argoumlinstaller/build-release.sh. You also need to create the releases-directory at the top of the SVN repository.

  3. Create the release branch/tag and checkout that copy.
  4. This is done using the command ./build-release.sh -tc in the argoumlinstaller project and giving the release name.

  5. You must have set JAVA_HOME for this to work.
  6. The script will check that the releases top directory is present in all the involved projects and that the given release name is not already present in any of the involved projects.
  7. Set the version to not include the "PRE-" part and commit the files.
  8. This is done in the ArgoVersion.java-file in build/VERSION_GIVEN_VERSION/argouml/src/argouml-app/src/org/argouml/application and in the build.xml-file in build/VERSION_GIVEN_VERSION/argouml-documentation.

  9. Build ArgoUML and the sub-projects, and sign the jar files.
  10. This is done using the command ./build-release.sh -bs

  11. Build the pdf version of the documentation.
  12. This is done using the command ./build-release.sh -d

  13. Go through Issuezilla and check things.
  14. Things to check are:
    1. That there is a Version created in Issuezilla for the newly created release.
    2. The purpose of this is to make it possible for everyone to report bugs on the new release.
    3. Make sure that the upcoming releases have target milestones created for them1. Also see that the numbering is the same in all components and that it is in the correct chronological order except for the not yet done releases that come before the already completed.

    4. Change the target milestones of all the not yet resolved issues for this release to ---.

    5. Change the target milestones of any fixed issue in component argouml with target milestone --- to that of the current release.

    6. This is probably some developer that has fixed an issue but forgotten to set the target milestone correctly.
    7. Move all issues reported on 'current' to this release (for the component argouml).
    8. These items were reported between the previous version and this version. Since 'current' will be reused for the next release, they need to be locked to the closest release to where they were found.
    9. Reopen RESOLVED/REMIND
    10. This can also be a good time to change all RESOLVED/REMIND. Search for them and Reopen them.
    11. Check RESOLVED/LATER
    12. It could also be good to check that all RESOLVED/LATER has a valid target milestone (must be an upcoming milestone). Search for them and Reopen the ones that haven't. Also, if the milestone denotes or is going to be resolved in the upcoming release, Reopen them with a comment that they are now active.
    13. For stable releases, decide on when FIXED issues that are RESOLVED or VERIFIED will be closed.
    14. Add a message to all VERIFIED issues and verify all RESOLVED issues stating when they will be closed. Suggested message:
    15. "The solution to this issue is included in 
      the stable release X.XX  that can be downloaded from 
      http://argouml-downloads.tigris.org/argouml-X.XX.
      
      If you, when you test this, find that the issue is 
      not solved, please reopen the issue. If you don't it 
      will be closed on 34th of Sebruary.
      
      If you find other problems when testing this, 
      please create a new issue."
      
    16. After that period, close all the issues unless they have been reopened. Suggested message:
    17. "The solution to this issue is included in 
      the stable release X.XX that can be downloaded from 
      http://argouml-downloads.tigris.org/argouml-X.XX.
      
      If you, when you test this, find that the issue is 
      not solved, create a new issue and mention this 
      issue in the description or as a reference."
      
  15. Run the installers.
  16. This is what you do:
    1. Create the zip files and the tgz files, copy the documentation, copy changed Java web start files and create new Java web start jnlp files.
    2. This is done by the command ./official.sh.

    3. For Java Web Start, update the "Latest development" or perhaps the "Latest stable" files essentially with the contents of the newly created JNLP file.
    4. These files are located in the argouml-downloads/www/jws-directory.

    5. Update the index files for the downloads project to point out the new release. The index.html is for the stable releases, the devrel.html for all releases.

    6. They should point out the release at /argouml-RELEASENAME/, the Java web start file at /jws/argouml-RELEASENAME.jnlp.

    7. Commit the release in the argouml-downloads project
    8. The following commands will do it for you:
    9. cd ../argouml-downloads/www
      svn commit -m'The release RELEASENAME.'
      
  17. Tag the argoumlinstaller directory.
  18. The following command will do it for you:
  19. svn copy \
      http://argoumlinstaller.tigris.org/svn/argoumlinstaller/trunk \
      http://argoumlinstaller.tigris.org/svn/argoumlinstaller/releases/VERSION_GIVEN_VERSION \
      -m'Installer used for GIVEN_VERSION.'
    
  20. Prepare the trunk for commits towards the next release.
  21. This is done by updating the PRE-VERSION in the trunk version of the files mentioned in 3

The are some extra considerations when /Making a Stable release.


CategoryFromCookbook

  • 1 This needs to be done for all components that has the same release scheme. This is the main reason we have everything that is released in the same component.

Making a release (last edited 2014-08-31 05:07:16 -0700 by linus)