RE: [Repast-developer] Evolutionaries and Revolutionaries

[Tom H. <th...@sr...>]

Well, I agree.  We've branched the tree before.  Merging is a nightmare,
but that's just the way it is.  However, one fundamental difference is
that the previous branch (the scheduler) was completely backwards
compatible.  First off, we should just get rid of space2.  It was a
brief playground I was using.  Secondly, I'm not convinced that we
should make any of the topology stuff backwards compatible (particularly
not the display stuff. Mark, we should discuss a game plan towards
this).  So, as such, I think that we should branch off the topology
stuff, with the long term plan of removing the space and network
packages all together.  I would also like to replace the current gui
package with a renderer package. I suppose all of this stuff could go in
the packages as the stand now (put your space stuff in the space package
as opposed to a topology package), but I think the meaning is better
with the new package names.  I'm not saying this so that we maintain
multiple implementations of space (I think we will want to get rid of
the old ones eventually), but I think the new package names are more
semantically meaningful.  We can deprecate the old ones.  I do think,
though, that we should branch off the topology stuff, we can decide
where we want it to go then.

-Tom

-----Original Message-----
From: rep...@li...
[mailto:rep...@li...] On Behalf Of Mark
R. Diggory
Sent: Monday, July 21, 2003 12:35 PM
To: repast-developer
Subject: [Repast-developer] Evolutionaries and Revolutionaries


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



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Repast-developer mailing list Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer