[EMAIL PROTECTED] writes: >> I have configured it to generate coverage data which shows the >> program lines that the test suite hits. I decided to upload the >> data in directories named by the build number: >> >> http://viff.dk/builds/22/coverage/ >> >> The corresponding API documentation is here: >> >> http://viff.dk/builds/22/api/ >> >> What do you think? > > Cool.
Thanks :-) I would like to extend this so that a full release-ready archive is built automatically by this system. Then it making a new release will be a simple matter of moving the latest build to /release and moving the API docs to /api. >> With this scheme, then I think we should let viff.dk/api return to >> being the latest released API docs. Or maybe a structure like >> >> viff.dk/api/latest >> viff.dk/api/0.1 >> viff.dk/api/0.2 >> viff.dk/api/0.3 >> >> like I suggested earlier. > > I prefer the latter. Most users will (should(?)) take a release > version as they are (or at least should be) better tested and more > stable. Well, right now I would be very pleased if the users would use any version at all :-) > And a user might not have the latest greatest so as support for > previous versions is simple, then why not have it? Yes, especially when we have close to infinite space available on DreamHost (for values of \infty close to 600 GiB...). So I will extract the API docs as they looked in the old releases and put them online as suggested above. I'll probably do this later today, right now I am looking at getting the unit tests working in a simulated asynchronous network. That is almost working as it should. -- Martin Geisler _______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
