|
From: Tom H. <th...@sr...> - 2003-07-21 18:16:46
|
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 |