On 21.09.2010, 21:48 Guillaume wrote:
I can see a number of reasons to have a stable trunk
(also used by
Wikimedia websites), that contains reviewed & tested code, along with a
development branch that /can/ be broken:
Things are currently reversed: stable (but outdated) branch and
bleeding-edge trunk broken 99% of the time. It doesn't really matter
how we do the development, this or other way around, the only problem
here is how often does the stable code gets updated.
* Developers wouldn't be afraid to commit
unfinished work to the
development branch fearing they're going to break trunk.
Even unstable trunk/branch is supposed to be runnable at all time, for
semi-finished features there are "private" branches. Several sites
(notably,
translatewiki.net) run off trunk, so even bleeding-edge code
shouldn't contain random chunks.
* Wikimedia users would probably not mind encountering
small bugs &
quirks if it's the downside of benefiting from more regular code
updates.
You got it wrong: the less often the updates go live, the more bugs
they contain due to the amount of untested code. Frequent updates
actually mean less bugs.
That said, I guess there are obvious drawbacks I'm
not seeing.
The problem here is that our stable code is way *too* stable.
Implementation details may vary.
--
Best regards,
Max Semenik ([[User:MaxSem]])