Vyatcheslav Yatskovsky schrieb: [...]
My experience of using open-source products (I'm best familiar with Moodle) suggest that there should be overlapping cycles in development: 1. Allocate new version number and start implementing new features. Many things are broken at the moment and the version becomes unusable for production purposes. 2. Stabilize this version and make definite release (number x.x.). Now it can be used for production. 3. Continue resolve bugs in this version AND perform Step 1 IN PARALLEL. [...] I think ConTeXt needs similar versioning model badly. Now it has rather naive model (release dates) that doesn't help in deciding about stability at all.
There is another reason for adopting a versioning model: legacy documents. I wonder how people (esp. at Pragma) currently deal with this. What happens if you have a ConTeXt doc from say 1997 that compiles into the resp. PDF with some ConTeXt version from that time but not today anymore? Which ConTeXt versions does one have to keep in order to be able to use such a document? (A good example for this kind of trouble seem to be the current issues with XeTeX, but I haven't followed this in detail -- but it kept me away from updating my ConTeXt installation since December...). Also remember that Knuth originally intended TeX to be an "eternal" formatting system (thus we have at least the option to expand all macros into plain TeX and keep that as the source file). This raises another question: is ConTeXt developed in an test driven way? I.e. are there test documents (including e.g. XML documents, bibligraphic references etc.) that have to pass comilation in order for changes to be published? If so, they would probably define a standard set of commands that could go into The ConTeXt Companion. Cheers Ulf