Joerg Heinicke wrote: > David Crossley wrote: > > > 3) The Forrest website is built using the "stable" version of > > Forrest (currently v0.5.1). So how will DTDs from the current > > CVS (v0.6-dev) get into the website CVS [3]? Manual copy? See 4). > > > > 4) If some committer changes the DTDs in CVS then they will be > > out-of-sync. Will committers remember to do the manual copy? See 3). > > I don't see this problem. On the one hand there are the older files like > document 0.10 or 0.11 that won't be touched, on the other hand 0.12 (or > is it already old too?) which is developed at the moment. You can't make > incompatible changes for one version, otherwise you will break possibly > thousands of documents out there. So only extensions are possible.
Absolutely. I think that i got a bit mixed up with whatever i was trying to say in item 4. We need proper version control and we have a naming convention for that. Forrest has been careful not to introduce any incompatible changes. However, i think that we need to be more careful about adding even new optional stuff. Every change should be a totally new DTD version. > In > conclusion: the update cycle must not be once per minute, but maybe once > per day or only week. Now what about having a cron job running on the > website server that checks out recent DTD versions? Forcing manual work > that's critical and without much effort automatically doable sounds not > that good. Good idea. Nicola Ken suggested something similar. I think that we need to be careful how far the automation goes. I mean that there are DTD versions in the HEAD CVS that are perhaps not yet ready to go public. Perhaps a deliberate manual process is better, but have a cronjob that reminds us if there are missing files on the website. > > 9) We will never know if the Catalog Entity Resolver gets > > broken after an upgrade. Forrest will still work but will > > be slower, doing downloads of the DTD and supporting files > > on each document parse. We can probably add a test document > > in the "forrest seed site" to detect failure. > > A really bad argument against the proposal :) Of course a real test is > the way to go here. I gather that you mean a "good argument". That is why i listed that issue. It would be a bad thing if Forrest/Cocoon silently started doing network retrievals like the current Xerces-2.6 web.xml issue. Forrest does now have a "build test" target which tries to build the "forrest seed site". Are you suggesting that we would be better to re-instate the JUnit tests that Cocoon used to have? I am no expert, but i think that we need the test to actually be a part of the Forrest machinery so that when users create a new "project" then they get the test happening too. --David
