6 This documents what is
done to create a gerbv release. The releases now
7 are
done by branching the sources
, fixing up the release version number
8 in the branch and
then tagging the release branch sources. The motivation
9 for a branch rather than a tag is to
make it easier to deal with setting
10 the release version number
in the documentation
, distfile
, and the
13 Note that the gyrations with maintainer-clean and another build are to
14 be sure that all the correct versions numbers end up
in the files.
16 After following the steps below
,
17 upload the
'gerbv-$VERSION.tar.gz' file to the sourceforge
file release system
20 NOTE
: Due to the way that the regression tests work they will usually fail
21 when run on a different machine
(different CPU
type for example
) than what
22 the
test suite golden files were generated on. To
let the rest of
'distcheck'
25 setenv GERBV_MAGIC_TEST_SKIP
yes
29 GERBV_MAGIC_TEST_SKIP
=yes
30 export GERBV_MAGIC_TEST_SKIP
32 To
make a gerbv release
do the following
:
34 =) Review the BUGS
file and
make sure it is up to
date.
36 =) # make sure it builds and makes distfiles ok:
38 .
/configure
--enable-maintainer-mode --disable-update-desktop-database
39 gmake maintainer-clean
41 .
/configure
--disable-update-desktop-database
46 =) Read the section
in src
/Makefile.am about the shared library versioning
47 and
make sure we have
done the right thing. Check
in src
/Makefile.am
48 if needed. This is critical. The version
*will
* change with every release
49 if *any
* changes have been made to the sources
for libgerbv. src
/Makefile.am
50 has specific rules
for how the versioning works.
52 =) if there were any new developers added
then update the
55 =) update the ChangeLog with
'cvs2cl.pl'.
56 .
/utils
/cvs2cl.pl
-U .
/utils
/umap
58 =) update the NEWS
file with some
sort of release notes.
59 I typically try to condense what I see
in ChangeLog
60 Check
in changes to NEWS and ChangeLog
62 =) if this is a major release
, then tag and branch
:
64 1. Tag the base of the release branch
65 cvs tag gerbv-2-3-base
67 2. Create the release branch
68 cvs tag
-R -b -r gerbv-2-3-base gerbv-2-3
70 3. On the trunk
, update configure.ac to update the version.
71 The rules
for versioning is that we append uppercase
72 letters to the branch version.
74 for example
2.3A after creating the gerbv-2-3 branch
79 4. On the release branch
, update configure.ac to update the
80 version. On a new branch
, add a
0RC1 to the teeny number.
83 cvs update
-PdA -r gerbv-2-3
87 4a.Ask users to
test the branch.
89 5. When the release branch is ready to go
, update configure.ac to
90 set the final release version. The first version from a
91 branch has
0 for the teeny version. For example
, 2.3.0.
93 cvs update
-PdA -r gerbv-2-3
96 cvs tag
-R -r gerbv-2-3 gerbv-2-3-RELEASE
98 Update the version on the branch to
2.3.1RC1
99 cvs update
-PdA -r gerbv-2-3
103 Update to the tagged released sources and build tarballs
104 cvs update
-PdA -r gerbv-2-3-RELEASE
106 .
/configure
--enable-maintainer-mode --disable-update-desktop-database
107 gmake maintainer-clean
109 .
/configure
--disable-update-desktop-database
112 If teeny version bumps are made
for a bug fix
, then the tag name
113 should be gerbv-2-3-PATCH001
for gerbv-2.3
.1,
114 gerbv-2-3-PATCH002
for gerbv-2.3
.2, etc.
118 openssl md5 gerbv-2.3
.0.
tar.gz
> gerbv-2.3
.0.
cksum
119 openssl rmd160 gerbv-2.3
.0.
tar.gz
>> gerbv-2.3
.0.
cksum
120 openssl sha1 gerbv-2.3
.0.
tar.gz
>> gerbv-2.3
.0.
cksum
122 8. Create a new
file release
for the package
"gerbv" with a release name of
123 "gerbv-2.3.0" (for gerbv-2.3
.0). Do this by logging into www.sourceforge.net
124 and
then navigating to
126 https
://sourceforge.net
/projects
/gerbv
(you must be logged
in to sourceforge
)
128 Pick Admin-
>File Releases
130 Next to the
"gerbv" package
, click
"Add Release"
132 In the
"Step 1: Edit Existing Release" section
, paste in the section of the NEWS
133 for this version. Check the
"Preserve my pre-formatted text" radio button and click
136 In the
"Step 2: Add Files To This Release" section follow the
"upload new files" link
137 and
then in the next page the
"Web Upload" link. You will have to log
in to
140 Upload the .
tar.gz
, .
cksum, and
if you built one
, the windows installer.
142 Once you have completed the
file uploads
return to the edit releases page
, check
143 the radio buttons next to the uploaded files and click the
"Add Files..." button.
145 In the
"Step 3: Edit Files in this Release" section
, set the following
:
147 .
tar.gz
- any
/ source .gz
148 .
cksum - Platform Independent
/ Other Source File
149 .exe
- i386
/ .exe
(32-bit Windows
)
151 You will have to click
"update" for each
file as you go.
153 In the
"Step 4: Email Release Notice" section
, check the
"I'm sure"
154 radio button and click the
"Send Notice" button.
156 9. Have a project admin go to the Admin-
>File Releases page and
then
157 follow the
"Create/Edit Download page" to change the default download
158 file to the new release.
160 10. Return to your regularly scheduled trunk development
164 =) if this is a
patch release
(2.3.1 for example
), then simply
165 make desired changes to the branch
:
167 cvs update
-PdA -r gerbv-2-3
171 update the version
for the release
176 cvs tag
-R -r gerbv-2-3 gerbv-2-3-PATCH001
178 update the version on the branch to
2.3.2RC1
183 update to the tagged release sources and build tarballs
184 cvs update
-PdA -r gerbv-2-3-PATCH001
186 .
/configure
--enable-maintainer-mode --disable-update-desktop-database
187 gmake maintainer-clean
189 .
/configure
--disable-update-desktop-database