1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
*** Introduction ***
This document describes how to do a flexdock release. It assumes the following
things:
- versioned releases are done off of the HEAD of the trunk branch of the
project in CVS
- there is an effective project freeze during the time of the release where
no one except those doing the release commit onto the trunk branch
- all future development work is located on branches and will be merged to
trunk after the release is performed
- if a problem is found shortly after the release, and future release work
has already been merged to trunk, a ..release (e.g. will be done by
creating a .. release branch, repeating the release with the new .. version
number relative to that specific branch and once the files are released to
the server, merging the ..release fixes to the trunk branch.
This may change in the future, but is a very simple release management approach
for the time being.
*** About Native Code ***
Currently, native code for a flexdock build is checked into the project. For
the time being we will trust that committers of C code check in updated
linux-x86 and windows libraries when changing the C code.
Therefore, a releaser does not need to figure out how to build native code.
In the future we will add checks to the build process to ensure that the commit
timestamps of the native code libraries are newer. This will help us detect
the obvious case where someone updates the C code without updating the native
code library
*** Diffing dirtrees/zips ***
The instructions below call for diffing of directory trees and/or zips. You
cannot just use diff to do this as you will need something that can recurse
into zip/jar archives. If you are release on Windows, then consider using
BeyondCompare (it's got a try/buy license). I'm not sure what UNIX tools are
available yet, but will research to make ensure there's no reason not to follow
the directions below on UNIX system.
*** Instructions for Performing a Release ***
If at any point you run into problems and have to change code to do the
release, restart at the first step (or at least make sure that all code is
committed back to HEAD in the clean working copy you create in step 1). We
want this to be repeatable.
Note: the files located in the www directory are used by java.net to display
the flexdock home page. Since the contents of these pages are dependent upon
the release, these files will NOT be updated until after the new flexdock
version are archived on the web site.
1) Create a clean CVS working copy from HEAD of trunk branch
2) Ensure that "version" property in build.xml is matches that for the
upcomping release. If it does not,
a) update build.xml to specify the proper version number in the "version"
property
b) test that you haven't broken the build.xml by doing a build and noting
that the generated artifacts use the new version number in their file
names
c) commit the build.xml with the updated version number to CVS
3) Test that you can run:
a) ant clean
b) ant dist
and that the build dir contains:
flexdock-[version].jar
flexdock-[version]-src.zip
dist/flexdock-[version].zip
dist/flexdock-demo-[version].jar
4) Verify that the demo app runs and reports the correct version. To do this
run:
java -jar build/flexdoc-demo-[version].jar
5) Verify that the src.zip can be used to produce the same output as a build
from CVS. Instructions
a) make a new dir
b) cd to that dir
c) expand flexdock-[version]-src.zip from the CVS build/dist dir
d) run 'ant dist' from the exp
e) run a recursive differ on that dir and the CVS dir ignoring timestamps
and CVS dirs. Verify that there are no differences
6) Tag the release. To do this, you can tag the remote trunk branch or the
working copy (assuming that the working copy is representative of trunk
HEAD, i.e. if you had to change anything else, you've committed it).
The format of the tag should be: flexdock_[major]_[minor]_[patch]. For
example flexdock_0_4_0.
To tag the from the working copy
cvs tag [versiontag]
for example
cvs tag flexdock_0_4_0
* This'll probably be replaced with some ant targets later on
** the tag scheme is pretty simple now and will probably be enhanced when we
start doing dailies/weeklies and/or preview releases
7) Create a clean CVS working copy from the tag created in the previous step
8) in that working copy run
a) ant clean
b) ant dist
9) diff the dist dir contents ignoring timestamps of the files and entries of
the zips and jars in this working copy's build/dist dir to the build/dist
dir of the working copy where you performed the tag two steps ago.
10) if #9 shows they are the same, then release the files
a) Log into flexdock.dev.java.net
b) Go to the "Documents & files" section of the project
c) Select "Add new file"
d) From the CVS versioned working copy add the file
build/dist/flexdock-[version].zip (NOT THE JAR):
i) Specify as the file name the same name as the file in the working
copy (without the path)
ii) As a description put "FlexDock [version] Binary Release"
(substituting the right version number of course)
iii) Select the zip file from the working copy via "Browse" button next
to the "Attachment" radio button in the "Contents" section
e) repeat c&d for the build/dist/flexdock-[version]-src.zip file, but use
the description "FlexDock [version] Source Release"
11) Update the index.html file, the web start JNLP file, as necessary and copy
the flexdock versions into the www area with:
a) ant webstartapp
|
