 |
. : News | Screen shots | Bugs | TODO |
Supported cards
Downloads
UMTS info
Authors
Sponsors
Extra docs
Developer's
mailing list
How to release the next version of umtsmon
CVS server: umtsmon.cvs.sourceforge.netlogin: kvangend
passwd: #######
obtaining a new tree
Do this when you are in a directory that does not contain a subdir umtsmon yet. This command will prompt for the password and then create a directory umtsmon in your current folder.
export CVS_RSH=sshcvs -z3 -d:ext:kvangend@umtsmon.cvs.sourceforge.net:/cvsroot/umtsmon co -P umtsmon
updating an existing tree
Do this when you are inside the umtsmon directory
cvs -qz9 update -dPadding new files to a repository
Do this when you are inside the umtsmon directory.
committing all changes to a repository
Do this when you are inside the umtsmon directory
cvs -n commit -m "checkin message" [optional list of filenames]cvs commit -m "checkin message" [optional list of filenames]
comparing against a repository
Do this when you are inside the umtsmon directory.
Every flag after diff is passed on to diff, so pass your favourite diffing flags here.
cvs diff --brief [filenames]
releasing
version numbering
According to Seife (with some modifications by Klaas), we should use the following version numbering:
- 0.5-$x, 0.6-$x, 0.7-$x (with $x being the RPM buildnumber) for final releases
- 0.7.1-$x for eventually needed intermediate releases (think "security fix")
- 0.5.9.$date-$x for intermediate CVS snapshots, whatever is in CVS then, i.e. 0.6-alpha
- 0.5.91.$date-$x once we reached "0.6 RC1" stage
- 0.5.92.$date-$x once we reached "0.6 RC2" stage
This means, that if you do a regular release, you'll have to change the version number inside
the software (in umtsmon_global.h) accordingly.
After you've made the release, be sure to update the file again to put the new number in it.
There shouldn't be any locally modified files or unknown files (starting with a question mark). Now we're going to tag the files for a release:
cvs tag -R [releasename]Moving of existing tags to a different revision is also possible, but shouldn't happen. If you really need it, here's how:
cvs tag -F [label] [filename]Note that within tags several characters are not allowed, including the space and the dot.
We're now going to checkout based on the above tag.
cd [temp dir]
export CVS_RSH=ssh
cvs -z3 -d:ext:kvangend@umtsmon.cvs.sourceforge.net:/cvsroot/umtsmon checkout -r umtsmon0_9 -P umtsmon
We now have a directory with the sources in the right tagging. Let's fixup for the source release
export UMTSV=umtsmon-0.3mv umtsmon $UMTSV
find . -name CVS -exec rm -rf {} \;
The find probably did return a few "No such file or directory" errors, that's not a problem.
tar czvf $UMTSV.src.tar.gz $UMTSV/*Rest of the procedure:
- build it:
make -C $UMTSV
lrelease $UMTSV/umtsmon.pro
strip $UMTSV/*
cp $UMTSV/images/128/umtsmon-128x128.png $UMTSV - create a binary archive of the binary/binaries:
tar czvf $UMTSV.i386.tar.gz $UMTSV/umtsmon $UMTSV/README $UMTSV/COPYING $UMTSV/AUTHORS $UMTSV/TODO $UMTSV/INSTALLING $UMTSV/umtsmon-128x128.png $UMTSV/umtsmon.desktop $UMTSV/i18n/*.qm - test the binary again, do not forget to verify some translations
- create Changelog:
Run the umtsmon-changelog script with appriopriate tags, e.g.:
./umtsmon-changelog --start-tag umtsmon0_8_91 --end-tag umtsmon0_9 - upload the files to sourceforge ( see sourceforge docs)
- go to admin website to create a release.
- pick the right name and click "Add Release"
- enter the right release name, e.g. "umtsmon-0.9rc1"
- Step 1:
upload/paste the release notes and the Change Log and click Submit/Refresh - Step 2:
pick the right files and click Add Files and/or Refresh View - Step 3:
set the right properties per file and click Update/Refresh - Step 4:
verify the above and check I'm sure. Then click Send Notice.
- on the SF website - that is a separate action!
- on Freshmeat click "add release"
- on PharScape
- etc.
