- Project tools
-
-
- Using ArgoUML
-
- The ArgoUML Project
-
- Nightly builds of docs
-
- The Stats Project
-
- How do I...
-
| Category |
Featured projects |
| scm |
Subversion,
Subclipse,
TortoiseSVN,
RapidSVN
|
| issuetrack |
Scarab |
| requirements |
xmlbasedsrs |
| design |
ArgoUML |
| techcomm |
SubEtha,
eyebrowse,
midgard,
cowiki |
| construction |
antelope,
scons,
frameworx,
build-interceptor,
propel,
phing
|
| testing |
maxq,
aut
|
| deployment |
current |
| process |
ReadySET |
| libraries |
GEF,
Axion,
Style,
SSTree
|
| Over 500 more tools... |
|
The purpose of this chapter 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/src_new/build.xml and
other build.xml files
are reused.
Prerequisites (what you need to be able to do this):
Subversion access to the argouml projects (to create the releases branch/tag).
The projects involved are specified by
argoumlinstaller/build-release.sh.
Subversion access to the argouml-downloads project (to upload the result).
A machine with 3GB of disk to use for this purpose
(September 2006).
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 2 GB) and
will take a considerable time to check out so you'd better do this in
advance.
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.
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:
Check for new projects.
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.
Create the release branch/tag and checkout that copy.
This is done using the command
./build-release.sh -tc
in the argoumlinstaller project
and giving the release name.
You must have set JAVA_HOME for this to work.
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.
Set the argo.core.version
to not include the "PRE-" part
and commit the files.
This is done in the default.properties-files
build/VERSION_GIVEN_VERSION/argouml/src/argouml-app
and
build/VERSION_GIVEN_VERSION/argouml/documentation/build.xml.
Build ArgoUML and the sub-projects,
and sign the jar files.
This is done using the command
./build-release.sh -bs
Build the pdf version of the documentation.
This is done using the command
./build-release.sh -d
Go through Issuezilla and check things.
Things to check are:
That there is a Version created in Issuezilla for the newly created release.
The purpose of this is to make it possible for everyone
to report bugs on the new release.
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.
Change the target milestones of all the not yet resolved issues
for this release to ---.
Change the target milestones of
any fixed issue
in component argouml
with target milestone ---
to that of the current release.
This is probably some developer that has fixed an issue but forgotten to
set the target milestone correctly.
Move all issues reported on 'current' to this release
(for the component argouml).
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.
Reopen RESOLVED/REMIND
This can also be a good time to change all
RESOLVED/REMIND.
Search for them and Reopen them.
Check RESOLVED/LATER
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.
Run the installers.
This is what you do:
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.
This is done by the command
./official.sh.
For Java Web Start,
update the "Latest development" or perhaps the
"Latest stable" files
essentially with the contents of the newly created JNLP file.
These files are located in the
svn/argouml-downloads/www/jws-directory.
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.
Commit the release in the argouml-downloads project
The following commands will do it for you:
cd ../argouml-downloads/www
svn commit -m'The release RELEASENAME.'
Tag the argoumlinstaller directory.
The following command will do it for you:
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
2.12.1. The release did not work![[Warning]](images/warning.png) | 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.
2.12.1.1. 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.
2.12.1.2.
Delay the release waiting for someone to fix the problem.
Create the branch as described in
Section 2.12.1.1, “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.
|
