5d1c45d48b5f0543932a68b7cbadc1e50e6b68c6
[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 On the new branch:
19
20     vi sys/sys/param.h      
21
22 Edit \__DragonFly\_version and related comments.  Be sure to add a comment for the new master too (but the version is set to the new release).
23
24     vi sys/conf/newvers.sh  
25
26 Edit BRANCH, use 'RELEASE', update version.  e.g. RELEASE_2_8
27
28 On master
29
30     vi sys/sys/param.h
31
32 Edit \__DragonFly\_version and related comments.
33
34     vi sys/conf/newvers.sh  
35
36 Edit BRANCH, use 'DEVELOPMENT', update version.
37
38 ##Tagging
39
40 Make sure all changes on the master branch and on the new branch have been committed and pushed before tagging anything.
41
42 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.
43
44 ###In master
45
46     git tag -s -m "DragonFly 2.x.x" v2.x.x
47     git push --tags
48
49 ###In the new branch
50
51     git tag -s -m "DragonFly 2.x.x" v2.x.x
52     git push --tags
53
54 Do the x.x.0 immediately.  Just before doing the final nrelease build roll a x.x.1 tag for the release branch.  Release as x.x.1.
55
56 ## Subsequent tag updates
57
58 When updating a x.x.1 version, you just need to edit sys/sys/param.h in the appropriate branch and then tag.
59
60 \__DragonFly\_version should be set to the appropriate minor number.  300000 changes to 300001, for instance, for 3.0.0 to 3.0.1.
61
62 ## Something in GCC
63
64 The file gnu/usr.bin/cc41/cc_prep/config/dragonfly.h has a spot where the major version number for DragonFly is encoded.  I don't know if this applies for anything other than gcc 4.1.
65
66     #define        DFBSD_MAJOR     3
67
68 This comes from John Marino's commit:
69
70 <http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/43add724990da155c21ef4a0893f4ebc2c36eb05>
71
72 ##Pkgsrc 
73
74 Adjust bulk builds to the release's pkgsrc branch, and make sure they upload to the right directories on avalon.dragonflybsd.org.
75
76 Adjust the default pkgsrc checkout in /usr/src/etc/Makefile.usr for both master and the new branch if necessary.
77
78 ###build isos and imgs
79
80
81
82 ###build pkgsrc packages
83
84 ###Testing
85
86 Testing should be done on real hardware, qemu and vmware. We have six isos/imgs that needs testing.
87
88 i386 iso, img, gui-img<br/>
89 x86_64 iso, img, gui-img
90
91 Test this:
92
93 * Booting install media.
94 * Installing; encrypted, unencrypted, ufs, hammer.
95 * Configuring everything in the installer; try both dhcp and static IP.
96 * Booting the installed system.
97
98 ###Release Notes
99
100 Copy one of the existing release pages.  The general format is :
101
102 * General announcement
103 * Big items new to this release
104 * Availability, describing what can be run
105 * MD5 results for compressed and uncompressed files
106 * Special notes and caveats
107 * Release notes - go through git log for these.
108
109 #### Minor releases
110
111 * Update the release page, the main page, and the general [[Download]] page.
112 * Add new MD5 sums.
113
114 ###File Copy
115
116 Place images in /ftp/iso-images on crater.dragonflybsd.org.  They will be rsynced to mirror-master.
117
118 ###announce
119 users@, web page