[mapguide-psc] road map planning

[Jason Birch]

That layout looks good to me, given Bob's hatred for the even/odd system
;)

I would also suggest that we want a consistent fixed cutoff date for
branching in prep for release.  Also, an appeals process more rigorous
than change requests (ie unanimous) for including any additional
functionality after a release cutoff.  

As far as version control goes, a policy of creating a branch for each
minor release, but only tags for bugfix releases?

I'm a bit fuzzy on using wish list items for the road map.  Obviously if
we're a good OS project we'll be responsive to our users, but to a
certain extent these wish list items will only be implemented through
change requests.  I think that perhaps we need a process like userland
wish list -> PSC's concept of "The Road Ahead".  All change requests
could be evaluated in light of this TRA document and their own merit and
then slotted into the Road Map.  That way users wouldn't be getting all
excited about a road map that contains items that might never get done,
and developers would have a good idea of what's important to the
community?

Sounds like I need to go off and buy an Open Source book or two.  Got an
ISBN Tom? :)

Jason 

-----Original Message-----
From: Paul Spencer [mailto:pspencer at dmsolutions.ca] 
Sent: Friday, October 20, 2006 05:45
To: psc at mapguide.osgeo.org
Subject: [mapguide-psc] road map planning

All,

I'm keen to lay out the framework for a road map for MGOS.  I have a few
suggestions to help us get organised.  Primarily I think the road map
should be organised around the planned release schedule and versions.
Central to my proposal is the concept of version numbering.  We do need
to have a version numbering discussion, so I'll lay out my thoughts
here.

A MGOS version number consists of 3 numeric fields separated by a
period, X.Y.Z <tag>.  X is the major version number, Y is the minor
version number and Z is the bugfix release number.  Version numbers can
be tagged with a descriptive title as well, for instance BETA or RELEASE
CANDIDATE.

Rules for changing version numbers on release need to be established,
here is my first cut at it (but it will need to be fleshed out some
more):

* Changes to the major version number happen when the software undergoes
substantial architectural changes and/or has a substantial set of new
features.

* Changes to the minor version number happen when the software undergoes
minor architectural changes, improved performance and stability, some
new features, or any changes to the existing published API.

* Changes to the bugfix release number happen for bug fixes and trivial
changes.

Version numbers can be useful when laying out a road map, if we look at
the road map as a series of releases.  The PSC can, at a high level,
agree on a release schedule and slot features etc into the appropriate
slots.

Timing of releases can be planned around the release numbers.  I propose
that we adopt the MapServer release strategy, which is as
follows:

1. Release a minor version approximately every 6 months regardless of
what has been done.  This has several advantages which I will only bring
up if the group disagrees with this strategy :)

2. Bug fix releases are then done approximately 'whenever' ...  
essentially as often as needed, but typically one release within a month
or two of the minor release and then maybe one more before the next
minor release - depends on the stability of the software and the
criticality of the bug fix - sometimes MapServer waits to accumulate
several minor bugfixes and sometimes they release with only one major
bugfix.

3. Major version releases happen irregularly and depend on actual
features implemented.  Essentially, enough stuff has to happen to make
it worthwhile.

My suggestion is that the PSC should be planning on major releases
somewhere between the .3 and .6 minor version of the previous major
release ... between 18 months and 3 years essentially, although it could
happen more quickly too.

Given all the preceding is ratified by the PSC (or some reasonable
facsimile), the outline of the road map for MGOS might be:

MapGuide 1 - Current

   MapGuide 1.0.0 - Released ???

     MapGuide 1.0.1 - Released ???

     MapGuide 1.0.2 - Released Oct 14 2006

     MapGuide 1.0.3 - as required

   MapGuide 1.1.0 - December 2006

   MapGuide 1.2.0 - June 2007

   MapGuide 1.3.0 - December 2007

   MapGuide 1.4.0 - June 2008

MapGuide 2 - Future

   MapGuide 2.0.0 - Unscheduled


We would then start to accumulate wishlist suggestions and tentatively
slot them into minor and major releases.  Due to the nature of open
source, we can't actually predict what will end up in any given release
because we need to find volunteers or contributors to get each piece
done.

But if we have a plan of what we would like to see, ADSK, DMSG and
others will be influenced by the road map and hopefully it will have a
greater chance of becoming reality :)

Cheers

Paul

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+