On Saturday, March 22, 2003, at 11:13 AM, Stefano Mazzocchi wrote:
Perhaps it's just the nature of open source software, that a tremendous amount of energy is unleashed right before a release date. Perhaps there's no other way. Still, it feels, to be honest, like poor planning. If we follow the maxim of "release early, release often" I fail to see why there needs to be this kind of disruption before releases. If the releases weren't spaced so far apart, what difference would it make if we need to wait a little longer for some new capability?
This is a very good point. So, do you suggest to postpone forrestization for post-2.1? say for 2.1.1?
Not necessarily. It depends on how much time we still have. And forrestization can occur in stages.
For example, current forrest build capability with cocoon's cvs is ony possible with Forrest CVS, not the last Forrest release. This violates your "building on sand" philosophy. We can change our cvs to work with 0.4 Forrest, but it involves committing doc-v11 versions of many files and deciding what to do with doc-v10-related files. If we simply eliminate the doc-v10 files, we will break the separate doc-building capabilities of our webapp documentation set. If we keep both versions, we have a maintenance nightmare. This is being discussed on cocoon-docs, with debate on how/if to include Forrest itself in our cvs, but there's no consensus yet, IMHO. Whatever solution is decided may take some time and tweaking to implement, that's all. And I would hate for it to hold up a release.
All right. Since there is circular dependency between cocoon and forrest, I would suggest we release cocoon 2.1 first, allow forrest to release a new version based on 2.1 and at that point forrestize our docs.
how does that sound?
Stefano.
