Corrected mdocml config.h patch to new location.
[ikiwiki.git] / docs / developer / Release / index.mdwn
1 #The art of releasing
2
3 This is a template on how to do a release.
4
5 ##Branching
6
7 On crater branch the repo:
8
9     cd /repository/git/dragonfly.git
10     git branch DragonFly_RELEASE_x_y        (e.g. 2_8)
11
12 This is the only step that needs to happen remotely.
13
14 On your own system:
15
16 Check out two copies of /usr/src, one with master checked out, one with the new release branch checked out.  Checkouts should be under your user id, NOT as root, or the later tagging operation will be unhappy.
17
18     mkdir master
19     cd master
20     git init
21     git remote add origin ssh://crater.dragonflybsd.org/repository/git/dragonfly.git
22     git fetch origin
23
24     cd ..
25     cp -R master x_y 
26     # x_y is the release; faster than rechecking out
27     cd master
28     git checkout master
29     cd ../x_y/
30     git branch DragonFly_RELEASE_x_y origin/DragonFly_RELEASE_x_y
31     git checkout DragonFly_RELEASE_x_y 
32
33 On the new branch:
34
35     vi sys/sys/param.h      
36
37 Edit \__DragonFly\_version and related comments.  You only need to add a commented version number for the branch, not the new master.
38
39     vi sys/conf/newvers.sh  
40
41 Edit BRANCH, use 'RELEASE', update version.  e.g. RELEASE_2_8
42
43     vi gnu/usr.bin/groff/tmac/mdoc.local
44
45 In the "Default .Os value" section, bump up the version to that of the release (even minor number).
46
47     vi etc/Makefile.usr
48
49 Adjust the default src checkout in /usr/src/etc/Makefile.usr to pull this branch.  Otherwise, anyone using the Makefile to download source will get master, and nrelease will build master.
50
51 Update OSNAME for mdocml:
52     
53     vi usr.bin/mandoc/config.h
54
55 On master:
56
57     vi sys/sys/param.h
58
59 Edit \__DragonFly\_version and related comments.  Put in commented numbers for the new release and master.
60
61     vi sys/conf/newvers.sh  
62
63 Edit BRANCH, use 'DEVELOPMENT', update version.
64
65     vi gnu/usr.bin/groff/tmac/mdoc.local
66
67 In the "Default .Os value" section, bump up the version to that of the master (odd minor number). Additionally, in the "DragonFly releases not found in doc-common" section, add a new line (a la the previous ones) for the new master.
68
69 Update OSNAME for mdocml:
70     
71     vi usr.bin/mandoc/config.h
72
73
74 ## Safety check
75
76 Before you tag, make sure there aren't any last minute surprises - build this new branch, current version, whatever.
77
78 ##Tagging
79
80 Make sure all changes on the master branch **and** on the new branch have been committed and pushed before tagging anything.
81
82 On release:
83
84     git add sys/sys/param.h sys/conf/newvers.sh gnu/usr.bin/groff/tmac/mdoc.local etc/Makefile.usr contrib/mdocml/config.h
85     git commit
86     git push
87
88 On master:
89
90     git add sys/sys/param.h sys/conf/newvers.sh gnu/usr.bin/groff/tmac/mdoc.local contrib/mdocml/config.h
91     git commit
92     git push
93
94
95 man git-tag for info, the committer needs GPG set up so git tag -s works.  Then you can use your own checkout.  Be sure the checkouts are under your user id and you do the tagging as yourself instead of as root.
96
97 You may need to set GPG_TTY to get GPG to work if it tries to run pinentry-curses.  This is the line for bash, since that's quoted most often for this fix.
98
99     export GPG_TTY=$(tty)
100
101 For tcsh:
102
103      setenv GPG_TTY `tty`
104
105
106 ###In master
107
108     git tag -s -m "DragonFly x.x.0" vx.x.0
109     git push --tags
110
111 ###In the new branch
112
113     git tag -s -m "DragonFly x.y.0rc" vx.y.0rc
114     git push --tags
115
116 Do the x.x.0rc immediately.  Just before doing the final nrelease build roll a x.x.0 tag for the release branch - the same method, just without "rc" for release candidate.  Release as x.x.0.
117
118 A new tag may require a commit beforehand to the release branch to make sure it goes to the right branch.
119
120 ## Subsequent tag updates
121
122 When updating a x.x.1 version, you just need to tag.
123
124 If there's a significant change between versions - major library change or third-party software update, which is more likely in the development branch of DragonFly - update param.h
125
126     vi sys/sys/param.h 
127
128 ## updating UPDATING
129
130 Generally, any files not specifically mentioned above as specific to a branch should be updated in master and then cherry-picked to the release branch.  src/UPDATING is the most common example.
131
132
133 ##dports
134
135 Adjust the default pkg checkout in /usr/src/etc/Makefile.usr for both master and the new branch if necessary.
136
137 DragonFly-current looks to the next even number release, so until the path is created on mirror-master,  ${ABI} will have to be set manually in /usr/local/etc/pkg/repos/df-latest.conf by any -current users.
138
139 dports for the new release should be built before announcing, so that people testing the release, or a release candidate, can install with immediately available packages.
140
141 ### Build isos and imgs
142
143 Make sure there's an appropriate dports path for pkg to download from when building images - especially release candidates.  When there is a major version change, the packages for master will not be named correctly.  (i.e. going from 3.8 to 4.0 means that the master packages were in 3.10, and the directory arrangement will reflect that).  Tag, get packages built, **then** create initial ISO/IMG files.
144
145 Set DPORTS_PATH when building the image to pick where dports comes from.  Ideally, there should be a release tag in dports that corresponds with the DragonFly release.
146
147     git fetch --tags
148     git checkout TAGNAME
149
150 If your ISO is too big for a normal CD, try stripping modules.  Make sure to use a blank make.conf so local changes don't interfere.  Here's the "final" string:
151     
152     make -DINSTALLSTRIPPEDMODULES DPORTS_PATH=/the/path  __MAKE_CONF=/dev/null release
153
154 To build it.  (add pkg/gui/whatever targets as necessary.)
155
156 ###Testing
157
158 Testing should be done on real hardware, qemu and vmware. We have six isos/imgs that needs testing.
159
160 i386 iso, img, gui-img<br/>
161 x86_64 iso, img, gui-img
162
163 Test this:
164
165 * Booting install media.
166 * Installing; encrypted, unencrypted, ufs, hammer.
167 * Configuring everything in the installer; try both dhcp and static IP.
168 * Booting the installed system.
169
170 ###Release Notes
171
172 Copy one of the existing release pages.  The general format is :
173
174 * General announcement
175 * Big items new to this release
176 * Availability, describing what can be run
177 * MD5 results for compressed and uncompressed files
178 * Special notes and caveats
179 * Release notes - go through git log for these.
180
181 Complete, or at least mostly complete, before announcing any versions.
182
183 #### Minor releases
184
185 * Update the release page, the main page, and the general [[Download]] page.
186 * Add new MD5 sums on the release page for the compressed and uncompressed files.
187
188 ### File Copy
189
190 Place images in /ftp/iso-images on crater.dragonflybsd.org.  They will be rsynced to mirror-master.
191
192 The file md5.txt should have the md5 output for all the compressed files.  It should also have the md5 output for the uncompressed images, so don't just 'md5 *bz2 > md5.txt'; get that separately and copy it into the document.
193
194 /root/adm/domd5.sh will get the MD5 sums for the compressed and uncompressed images and print them to stdout.  The script will run faster if you edit it to only check the new files, and then manually add the lines to md5.txt.
195
196 A BitTorrent setup would be desirable, but there's no standard process for it as part of release, yet.
197
198 ###announce
199 users@, web page, Hacker News, Slashdot, Reddit