/
ms-rfc-34.txt
156 lines (109 loc) · 5.62 KB
/
ms-rfc-34.txt
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
147
148
149
150
151
152
153
154
155
156
.. _rfc34:
==========================================================
MS RFC 34: MapServer Release Manager and Release Process
==========================================================
:Date: 2007/07/13
:Author: Daniel Morissette
:Contact: dmorissette at mapgears.com
:Last Edited: 2007/07/19
:Status: Adopted (2007/07/19)
Overview
--------
This RFC documents the MapServer Release Manager role and the phases of
MapServer's Release Process.
The MapServer Release Manager Role
----------------------------------
For every release of MapServer, the PSC elects a release manager (this
is usually done with a motion and vote on the mapserver-dev list).
The overall role of the release manager is to coordinate the efforts
of the developers, testers, documentation and other contributors to
lead to a release of the best possible quality within the scheduled
timeframe.
The PSC delegates to the release manager the responsibility and
authority to make certain final decisions for a release, including:
- Approving or not the release of each beta, release candidate and
final release
- Approving or rejecting non-trivial bug fixes or changes after the
feature freeze
- Maintaining the release schedule (timeline) and making changes as required
When in doubt or for tough decisions (e.g. pushing the release date by
several weeks) the release manager is free to ask the PSC to vote in
support of some decisions, but this is not a requirement for the areas of
responsibility above.
The release manager's role also includes the following tasks:
- Setup and maintain the Release Plan section of the website for
this release
- Coordinate with the developers team
- Coordinate with the QA/testers team
- Coordinate with the docs/website team
- Keep track of progress via Trac (make use of Trac milestones and ensure
tickets are properly targeted, push some tickets to a later release if
required, etc.)
- Organize regular IRC meetings (including agenda and minutes)
- Tag source code in SVN for each beta, RC and release
- Branch source code in SVN after the final release (trunk becomes the next
dev version)
- Update map.h and HISTORY.TXT for each beta/RC/release
- Package source code distribution for each beta/RC/release
- Update appropriate website/download page for each beta/RC/release
- Make announcements on mapserver-users and mapserver-announce for
each release
- Produce/coordinate bugfix releases as needed during the 6 months period
that follows the final release (i.e. until the next release)
Any of the above tasks can be delegated but they still remain the ultimate
responsibility of the release manager.
The MapServer Release Process
-----------------------------
(Credit: Inspired by the Plone release process at
http://plone.org/documentation/manual/plone-developer-reference/overview/release-process)
MapServer uses a time-based release cycle, trying to aim for one
release every 6 months.
The normal development process of a MapServer release consists of various
phases.
- Development phase
The development phase usually lasts around 4 months. New features are
proposed via RFCs voted by the MapServer PSC.
- RFC freeze date
For each release there is a certain date by which all new feature
proposals (RFCs) must have been submitted for review. After this date no
features will be accepted anymore for this particular release.
- Feature freeze date / Beta releases
By this date all features must have been completed and all code has
to be integrated. Only non-invasive changes, user interface work and
bug fixes are done now. We usually plan for 3-4 betas and a couple of
release candidates over a 6 weeks period before the final release.
- Release Candidate
Ideally, the last beta that was bug free. No changes to the code.
Should not require any migration steps apart from the ones required
in the betas. If any problems are found and fixed, a new release
candidate is issued.
- Final release / Expected release date
Normally the last release candidate that was issued without any
show-stopper bugs.
- Bug fix releases
No software is perfect. Once a sufficient large or critical number
of bugs have been found for a certain release, the release manager
releases a new bug fix release a.k.a. third-dot release (for example 4.10.2).
MapServer Version Numbering
---------------------------
MapServer's version numbering scheme is very similar to Linux's. For
example, a MapServer version number of 4.2.5 can be decoded as such:
- 4: Major version number.
We release a major version every two to three years. The major version
number usually changes when significant new features are added or when
major architectural changes or backwards incompatibilities are introduced.
- 2: Minor version number.
Increments in minor version number almost always relate to additions
in functionality and correspond to the 6 months release process
described in this RFC.
MapServer uses the same even/odd minor version number scheme as Linux.
Even minor version numbers (0..2..4..6) relate to release versions,
and odd minor versions (1..3..5..7) correspond to developmental versions.
For instance development version 4.1 was released as version 4.2.0, there
was never any formal release of 4.1.
- 5: Revision number.
Revisions are bug fixes only. No new functionality is provided in revisions.
Voting history
--------------
Vote completed on 2007/07/19.
+1 from DanielM, SteveL, SteveW, FrankW, TamasS, AssefaY, JeffM, PericlesN, UmbertoN and HowardB.