Hi, On Dec 21, 2007 1:46 PM, Mark Brouwer <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: > > My advice is not to use "development branches" if there's any way to > > avoid them. Each such branch is essentially a fork of the project. > > My experience is that how to implement a feature is often not that > obvious in the first place, also implementing such a feature could be a > cooperative development between a subset of committers that might have > lots of side effects and can take a long time span to materialize before > it can be decided whether the trunk should receive it.
I would classify it as a major architectural defect if there is a frequent need for features that can't be split to smaller steps, have lots of side effects, and require lots of effort implement. Apart from major architectural redesigns any new features should generally only affect one or just a few components within a project. Even for central API changes it should be possible to come up with an incremental upgrade path where existing components can keep using the previous API until they get upgraded. Instead of branching the whole project, it would IMHO be much better to use a sandbox of experimental components that should remain compatible with the trunk. Such components might be forked versions of "stable" components in trunk, but even for such cases I'd rather see the shared code being refactored to a base component that both the "stable" trunk version and the experimental snapshot component extend. > I used skunk branches for all work of which the outcome was not that > obvious or that I expect to take a significant time and for which I want > versioning of object while working on a feature and for which I would > like others to have a look without creating diffs that others have to > apply on some branch. It also allows for other committers to join the > development activity. I very much agree with the rationale of enabling communication over proposed changes, but couldn't such things be achieved on a smaller scale (i.e. individual components) than the entire project? > The philosophy of truly distributed software development is that each > developer could work in isolation (effectively forks) [...] I see what you mean, but one could also take the stand that isolation is the nemesis of collaborative software development. The more you isolate individual developers, the harder you make for them to effectively work together. > and later it is decided what is pushed or pulled into the trunk or between > workspaces of various developers. IMHO the more fine grained such integration is, the more cohesive, collaborative, and also effective the project is. Ideally those change-sets would be individual commits to trunk. Also, having a single codebase that everyone works on makes it much easier for new or occasional contributors to jump in without having to worry about which of any number of actively developed branches they should be looking at. Of course, these are just my experiences and opinions on collaborative open source development, and I'm not arguing that you should switch to this model if you're already happy with the current way of working. Just something to consider as a potential alternative. BR, Jukka Zitting
