[fdo-internals] FDO RFC 14 -- FDO Release Manager and ReleaseProcess

[Robert Fortin]

Some comments below:

Release Candidate
Ideally, the last beta that was bug free....

> This is optimistic. In general, this is the last beta where no major defect have been encountered (show-stopper) or where defects identified have been assessed.  I could be decided that the defect assessed will or will not be considered for the next candidate or final release (as suggested in the FDO Release Manager Role section: "Approving or rejecting non-trivial bug fixes or changes after the feature freeze")

Final Release / Expected Release Date ¶
Normally the last release candidate that was issued without any show-stopper bugs.

> ... without any known show-stopper bugs.  Again, show-stopper can exist for some situation that are not consider critical to the functionality.


FDO Version Numbering
Minor version

> Usually, we would try to keep binary compatibility within the same minor number and certainly between revision number (e.g. 3.3.0 and 3.3.1 are binary compatible).  Same thing for schemas (XML, file format or db).




-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Daniel Morissette
Sent: Friday, April 04, 2008 7:47 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 14 -- FDO Release Manager and ReleaseProcess

Here are some responses based on our experience with MapServer using the
same model for a few years now:

Orest Halustchak wrote:
>
> RFC Freeze Date: How do we determine that date? Will it be before end of
> development, e.g. 'n' weeks before end of development?
>

The idea of RFC freeze date was introduced only in our last release
(5.0) so we didn't really plan for it ahead of time for 5.0. However
setting a RFC freeze about 2 weeks before the planned Feature freeze
seems to make sense to me.

Actually I don't even see the RFC freeze listed in our 5.0 release plan
(archived at
http://mapserver.gis.umn.edu/development/release_plans/mapserver_5_0/release_plan/),
but if I remember correctly it was set 2-3 weeks before the feature
freeze date.

The RFC freeze date, Feature freeze date and target final release date
are all set at the time that we decide to release and voted by the PSC
in a motion. Then the release manager's job is to try to make the
release follow those dates.

>
> For RFCs that appear after the RFC freeze date, they can simply roll
> into the next release.
>

That's what we do.

>
>
> Feature freeze date: So, what do we do with any components that have not
> been completed by this date? They have to be removed from the release?
>

Well, we try to avoid committing half-baked features to the trunk, so
they don't need to be removed, they just wait to be committed until
after the trunk has been branched for the release.

Since we're not in a perfect world, there are always exceptions, and in
case some components cannot be completed in time for the feature freeze
then they are either disabled (#ifdef'd by default), or left active and
called experimental in the release notes.

>
>
> Beta releases: 2-3 betas plus a couple of release candidates seems like
> a lot of separate releases within that 2 month period.
>

For the MapServer 5.0 release we went even further and experimented for
the first time with weekly betas. That gave:

     * Feature freeze - July 23, 2007
     * 5.0.0-beta1 - Wed. July 25, 2007
     * 5.0.0-beta2 - Wed Aug. 1, 2007
     * 5.0.0-beta3 - Wed Aug. 8, 2007
     * 5.0.0-beta4 - Wed Aug. 15, 2007
     * 5.0.0-beta5 - Wed Aug. 22, 2007
     * 5.0.0-beta6 -  Wed Aug. 29, 2007
     * 5.0.0-rc1 -  Wed Sept. 5, 2007
     * 5.0.0-rc2 -  Mon Sept. 10, 2007
     * 5.0.0 (final) - Mon Sept. 17, 2007

... yes, that's lots, but that gave an excellent release. The weekly
beta announcements generated much more interest than usual in the users
community, they really saw the new release coming and I believe that
gave us more users testing and feedback. That also forced the developers
to keep moving since the next beta was never more than a few days away,
forcing them to fix their bugs right away instead of postponing (and
eventually forgetting) them.

Daniel
--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals