← Back to branch summary

~ubuntu-branches/ubuntu/precise/libxml-security-java/precise-security

« back to all changes in this revision

Viewing changes to ReleaseProcess.txt

  • Committer: Package Import Robot
  • Author(s): Torsten Werner
  • Date: 2011-08-30 14:07:46 UTC
  • mfrom: (1.2.2 upstream)
  • mto: This revision was merged to the branch mainline in revision 9.
  • Revision ID: package-import@ubuntu.com-20110830140746-wfmiluk1yddqd6ch
* New upstream release
* Update debian/watch to point to new SVN repo.
* Update Standards-Version: 3.9.1.
* Switch to source format 3.0.
* Use Maven to build the package. Ignore test failures.
* Update Description.
* Add a documentation package.
* Update Homepage field.

Show diffs side-by-side

added added

removed removed

Lines of Context:
ReleaseProcess.txt
 
1
 
 
2
                          Release Instructions
 
3
                          --------------------
 
4
                                
 
5
                                                                V0.1Draft
 
6
 
 
7
 
 
8
This document provides an outline of how to perform a release for the C or Java
 
9
XML-Security libraries.  (Hosted at http://xml.apache.org/xml-security.)
 
10
 
 
11
Document Authors : 
 
12
   Berin Lautenbach
 
13
 
 
14
NOTE: Based on ReleaseInstructions.txt from the Ant CVS
 
15
 
 
16
Announce Release Plan
 
17
---------------------
 
18
 
 
19
Propose a release plan for vote.  This should set out the timetable for
 
20
the release under ideal circumstances.  The level of bugs reported 
 
21
can delay things. Generally, give a few weeks to "close" the source tree 
 
22
to further changes so people can finalise contributions, etc. At this time,
 
23
the first beta will be cut and there will be then a period of beta testing,
 
24
usually 1 month but this should be flexible.
 
25
 
 
26
Note that any mention of a deadline causes a flood of bug fixes, new tasks,
 
27
etc.  This needs to be managed as best it can. Some fixes will be applied, 
 
28
others held over. Make this clear in the release plan. The committers and 
 
29
particularly the release manager will need to make judgement calls here. 
 
30
Anything too "big" is likely to be held over.
 
31
 
 
32
Create Branches in CVS
 
33
----------------------
 
34
    
 
35
Once the freeze date arrives, create a branch for the release builds. You 
 
36
will need to be comfortable in handling CVS branches with mutliple 
 
37
merge-backs to the main branch and even selected merges from the the main 
 
38
branch to the release branch.  
 
39
    
 
40
For more information on performing branching and merging, please visit
 
41
http://www.durak.org/cvswebsites/doc/cvs_54.php#SEC54
 
42
 
 
43
Label such branches XMLSECC_11_BRANCH (for C library branches) or
 
44
XMLSECJ_11_BRANCH (for Java library branches).
 
45
    
 
46
Once the branch is setup, the version numbers in CVS are changed. On the 
 
47
branch, the build.xml (Java) or configure.ac (C++) version becomes 1.1Beta1
 
48
while the main branch is updated to 1.2alpha. 
 
49
    
 
50
Build the Archives
 
51
------------------
 
52
 
 
53
Ensure your GPG/PGP key is in the keys.txt file in the CVS.
 
54
 
 
55
Export the xml-security module to a clean directory :
 
56
 
 
57
           cvs export xml-security
 
58
 
 
59
Label the branch XMLSECC_11_B1 or XMLSECJ_11_B1
 
60
 
 
61
** TODO - Create make process to build distributions and add commands here **
 
62
 
 
63
** Java guys - what are the instructions to build the archives? **
 
64
 
 
65
Sign the archives
 
66
-----------------
 
67
 
 
68
Sign the distribution files using the following simple script
 
69
#!/bin/sh
 
70
for i in distribution/*
 
71
do
 
72
     echo "Signing " $i
 
73
     gpg -a -b --force-v3-sigs $i
 
74
done
 
75
 
 
76
Try to do this on Linux since the gpg signatures generated on Windows may 
 
77
cause some PGP users problems verifying signatures even though they seem 
 
78
OK.
 
79
    
 
80
Also make sure you have sent the key that you use to a public 
 
81
keyserver.
 
82
 
 
83
Transfer to Apache Web Site
 
84
---------------------------
 
85
 
 
86
The beta distribution is now ready to go. Bundle it up into a tar.gz file 
 
87
and scp to your apache account.
 
88
 
 
89
** Do we have a standard set of WHATSNEW/README files? The would be updated
 
90
here **
 
91
 
 
92
Once this is uploaded, unpack things, create the release directory, 
 
93
something like v1.1Beta1, push the release and README files into this 
 
94
directory.
 
95
 
 
96
The files should go to /www/xml.apache.org/builds/xml-security/release
 
97
on daedalus.
 
98
 
 
99
** Is the above correct? **
 
100
 
 
101
Address the available release tags in BugZilla. Create a new tag 1.1Beta1 
 
102
and a 1.2alpha. Assign all existing 1.1alpha bugs to one of these release 
 
103
labels.
 
104
 
 
105
Test the distribtion
 
106
--------------------
 
107
 
 
108
Once that is done, do a test download to make sure everything is OK. A 
 
109
common problem may be:
 
110
 
 
111
    * the file's mime type is not recognized and is interpreted as 
 
112
      text/plain.  Fix it by using some .htaccess magic (AddEncoding stuff)
 
113
    * Your gz.asc files are not being displayed properly (RemoveEncoing stuff)
 
114
 
 
115
** What tests should be done to validate archives? **
 
116
    
 
117
If it looks OK, announce it on security-dev. After a few days pass and 
 
118
there are no major problems, a wider announcement is made (main xml 
 
119
website, general@xml.apache.org, etc).
 
120
    
 
121
** Any other files/lists to update? **
 
122
 
 
123
Announce beta releases at freshmeat.net (Do we have an entry?)
 
124
 
 
125
As problems in the beta are discovered, there may be a need for
 
126
one or more subsequent betas. The release manager makes this
 
127
call. Each time, the versions are updated and the above process is
 
128
repeated. Try not to have too many betas.
 
129
 
 
130
Try to advertise the need for testing of the betas as much as possible.
 
131
This should eliminate the need to release minor patch versions.
 
132
    
 
133
To monitor the number of downloads, look at the access_log
 
134
file under /usr/local/apache2/logs
 
135
 
 
136
When the final beta is considered OK, propose a vote on ant-dev to 
 
137
officially adopt the latest beta as the XML-Security-C/J 1.1 release. If it is 
 
138
passed,  (it usually does,) this would be labelled XMLSECC_11 or XMLSECJ_11
 
139
and built in a similar fashion to the above process.
 
140
 
 
141
BUT
 
142
 
 
143
This time the directory you upload the files to is different and
 
144
you'll have to do some house-keeping for the old release:
 
145
 
 
146
** NOTE I am guessing at all directories here **
 
147
 
 
148
    * create a directory for the old release in 
 
149
      /www/xml.apache.org/builds/xml-security/release on daedalus.
 
150
 
 
151
    * Move the release notes, .zip files and corresponding signatures
 
152
      and md5 hashes of the old release from 
 
153
      /www/www.apache.org/dist/xml-security
 
154
      to a matching directory structure in
 
155
      /www/xml.apache.org/builds/xml-security/release.
 
156
 
 
157
    * remove the remaining files except for the KEYS file from
 
158
      /www/www.apache.org/dist/xml-security.
 
159
 
 
160
    * upload the new release files to 
 
161
      /www/www.apache.org/dist/xml-security/[source|binary].
 
162
 
 
163
    * Create proper -current symlinks in /www/www.apache.org/dist/xml-security/
 
164
 
 
165
Change the links in /xdocs/bindownload.xml and /xdocs/srcdownload.xml,
 
166
regenerate the HTML files, commit and update the site.
 
167
 
 
168
As the mirrors may need some days to pick up the new release, you
 
169
may want to add a note to that effect to the pages and remove it a few
 
170
days later.
 
171
 
 
172
Now and perhaps during previous betas any changes on the branch must 
 
173
be merged back into the tree.
 
174
 
 
175
At this point in time, the release is done and announcements are made. 
 
176
 
 
177
**TODO: Identify the mailing lists where announcements are to be made.
 
178
Also identify the webpages to which the announcements must go. **
 
179
 
 
180
Apache mailing lists that should get the announcements:
 
181
announce@jakarta.apache.org, announce@xml.apache.org,
 
182
announce@apache.org and security-dev
 
183
 
 
184
Announce release at freshmeat.net
 
185
** Do we have an entry? **
 
186
 
 
187
You can now reacquaint yourself with your family and friends.