This is a big problem and it interacts with the user-selectable styles too, as you could use colored text in a posting unaware that someone else has chosen that as a background colour.
It's also what Craig and I are doing our talk about at MoodleMoot.
David Scotson
Мнения, написани от David Scotson
Well, you can if your CVS HEAD is static while development happens for long periods on an unstable branch that is usable by only the bravest of testers. A "release" generally suggests more than mere code availability.
However, I'm not saying that's what is going to happen. I'm just raising it as an issue as I got the impression that new (at least semi-) stable Moodle releases would cease for a period of months while a major rewrite occured.
If you're saying that templates will not be all-or-nothing affair and you're just marking 1.4 as stable for those who would be unwise to follow the latest developments until relative calm returns then I'm perfectly happy.
However, I'm not saying that's what is going to happen. I'm just raising it as an issue as I got the impression that new (at least semi-) stable Moodle releases would cease for a period of months while a major rewrite occured.
If you're saying that templates will not be all-or-nothing affair and you're just marking 1.4 as stable for those who would be unwise to follow the latest developments until relative calm returns then I'm perfectly happy.
Well the flagship models for time-based releases in large projects are Mozilla, Fedora/Red Hat, and the Gnome Desktop releases.
However I was thinking also of the general "release early, release often" rationale (which I think also goes under another name in XP lingo that I forget right now) common in smaller OSS projects that allows them to avoid straying too far from a stable, releasable state and instead releases even after minor or partial improvements are available (usually version 0.451 or somesuch).
It seems far more like a proprietary software trend to do lots of work under the covers and return with a largely rewritten product (usually accompanied in those cases by a major version number bump in order to justify the purchase price and leverage the advertising budget).
I've been thinking about it recently as I've been reading a great deal about delay's and slippage in Microsoft's next big release and how they seem to be replacing everithing at once and giving themselves major headaches for reasons more to do with their business model than their technology or coding ability.
However I was thinking also of the general "release early, release often" rationale (which I think also goes under another name in XP lingo that I forget right now) common in smaller OSS projects that allows them to avoid straying too far from a stable, releasable state and instead releases even after minor or partial improvements are available (usually version 0.451 or somesuch).
It seems far more like a proprietary software trend to do lots of work under the covers and return with a largely rewritten product (usually accompanied in those cases by a major version number bump in order to justify the purchase price and leverage the advertising budget).
I've been thinking about it recently as I've been reading a great deal about delay's and slippage in Microsoft's next big release and how they seem to be replacing everithing at once and giving themselves major headaches for reasons more to do with their business model than their technology or coding ability.
many non-developers are using CVS to run their Moodle sites.
Do you mean that non-developers are using CVS to pull from HEAD? If they are simply "using CVS" then surely pulling a tagged release isn't a major stumbling block. In fact, users running HEAD on production servers seems like a bad idea anyway, though obviously the more people running the latest code (e.g. Mozilla nightly builds) the faster regressions get caught, but anyone doing so should understand and accept the consequences of straying from the official releases.
I'm also wondering if you've thought about the benefits of time-based release as opposed to feature-based releases. Many other OSS projects have claimed to improve their stability by taking this approach.
I mention this as this discussion of branches seems to be based on the assumption that introducing templates will necessarily lead to Moodle (2.0?) being broken for a few months. Is there a technical reason why templates cannot be introduced in a gradual manner? Unless a total redesign is to accompany the introduction of templates (which seems unwise) then I would guess that the end-user would be none-the-wiser.
I've been working on doing this kind of thing with something based on Zeldman's javascript CSS style switcher:
http://www.zeldman.com/about/switch/
At the moment I'm just trying to adjust text-size but it is possible to achieve more adventurous changes.
However, I'm not sure how this system would interact with Moodle's styles.php file since it defines PHP variables as well as CSS styles. I'm trying to do without any PHP in order to implement all styles in CSS only, but doing so will require some minor changes to Moodle's HTML as some styles are only defined in this way.
http://www.zeldman.com/about/switch/
At the moment I'm just trying to adjust text-size but it is possible to achieve more adventurous changes.
However, I'm not sure how this system would interact with Moodle's styles.php file since it defines PHP variables as well as CSS styles. I'm trying to do without any PHP in order to implement all styles in CSS only, but doing so will require some minor changes to Moodle's HTML as some styles are only defined in this way.