[Repast-developer] Evolutionaries and Revolutionaries

[Mark R. D. <mdi...@la...>]

In the process of versioning any software development project there will 
always be the challenge of balancing Evolutionary (modifying the current 
  based while maintaining as much backward compatibility) and 
Revolutionary (creating new and novel approaches to solving a problem 
that are not necessarily backward compatible). There's always been allot 
of discussion about this process on the Apache lists.

This comes from a thread of discussion at Apache that has been 
formalized into a general policy for managing development in Open Source 
groups.

http://incubator.apache.org/rules-for-revolutionaries.html

How does this apply to the current RePast source tree? We need to 
consider how we will move forward with the development of the new space 
library and its relation to the old space library. Currently, we have 
taken what amounts to a "revolutionary" path by creating a new space 
package inside the topology package.

1.) Is this truly the location we want to work with new spaces in?

2.) Do we really want to support two different space libraries in the 
next version of RePast?

3.) The new space/topology package is starting to encounter limitations 
in attempting to retain backward compatibility with the old 
Discrete2DSpace interface. There are methods there that no longer seem 
ver relevant and can tend to confuse the user in the new api.

4.) I retained Backward compatibility against the Discrete2DSpace 
interface to allow rendering in Object2DDisplay to still work with the 
new library. But, upon reviewing the code in these displays I'm 
beginning to think I can even improve and consolidate these display 
classes in the same fashion as I have the consolidated the space library 
code. It is the case that in all new ObjectSpaces the Location can be 
used as a "List/Set" over which the Display rendering can occur and 
quite independent of the actual implementation underlying the 
Object2DSpace. I'd like to begin improving this code, but I'd like to 
avoid creating "new" Display classes to do this.


With these questions in mind, we should discuss the goals and future 
direction of both the space and the display packages and what we hope to 
improve and what we hope to maintain. I think that it is important to 
focus on the strategies we can take for approaching these goals in the 
cvs source tree.

1.) Branching vs creating new directories.

Branching is a means of establishing different "versions" of the source 
tree based on setting "tags" at appropriate versions in the source tree 
and then providing "branches" that constitute changes that are 
maintained only in that branch. The benefit of this approach is best 
seen at Mozilla.

http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html#tree-management

here mozilla maintains a number of branches that break from the trunk of 
the cvs at version releases, these provide stable positions to apply bug 
fixes and stablization releases for that particular release and 
constitute a means of keeping backward compatibility across minor 
changes with a major release branch. Commits to these branches are also 
applied back into the trunk to capture those changes across the entire 
project.

What this strategy provides is room on the main "HEAD" branch of the 
tree for more aggressive refactoring and modification without 
compromising the the release of minor improvements to the "release 
branches" themselves. Eventually, over time, release branches are 
"abandoned" as new releases are established. On the Mozilla timeline, 
this can be seen in that after a certain amount of time a branch 
"dissolves" as all the "bugs" are fixed and the release is stabilized.

When all the developers on a project are in one room, its allot easier 
to maintain a cvs tree thats branchless, because theres usually a common 
direction for all those developers. When a project becomes more "Open" 
to multiple groups and development by multiple groups, its more the case 
that branching is a necessity because developers from different groups 
are more "apt" to make changes that others in the group may not be 
prepared for, such changes also have a tendency to occur right after a 
major release, as the group tends to push individual developers not to 
make drastic changes until a stable release has been cut. Thus branching 
is critical to establishing stable backward compatible minor versioning 
while still allowing more aggressive refactoring on the main trunk.

Creating new directories is often a compromise which is made in smaller 
development groups with less knowledge of how to manage the cvs tree. As 
  a group grows larger, its often the case that this gives rise to large 
and complex directory structures in the cvs tree. I also think tends to 
produce packages that are difficult to connect together as "multiple 
interfaces/implementations can easily arise when developers are given 
"free reign" over the contents of a particular directory in the tree. 
For example: we currently have three current versions of spaces:

u.s.s.space
u.s.s.topology.space
u.s.s.topology.space2

eventually these multiple packages will need to be consolidated. This a 
benefit of using branching to manage evolution/revolution vs creating 
new directories for revolutionary development. the separate branches 
maintain different developmental versions of the project. Merging the 
branches periodically provides for changes across these various branches 
to be consolidated into the trunk itself. Eventually, when common 
agreement arises about the implementation, then a release can be cut.

This is often a process that requires both advanced knowledge of cvs and 
some intensive management by the developers, and is why small groups 
don't often do such. At some point in the future, if the RePast group 
continues to grow, some thought should go into converting to this sort 
of cvs strategy.

-Mark