[mapguide-psc] road map planning

[Andy Morsell]

Jason,
Regarding the Open Source book: I saw reference to this one this morning
http://producingoss.com/html-chunk/ from
http://hobu.biz/index_html/open-development 


Andy 

-----Original Message-----
From: Jason Birch [mailto:Jason.Birch at nanaimo.ca] 
Sent: Friday, October 20, 2006 9:51 AM
To: psc at mapguide.osgeo.org
Subject: RE: [mapguide-psc] road map planning

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/ |
+-----------------------------------------------------------------+