-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yes. Except that creating and XML lib in the rewrite
is a lot less
work than creating tests and cleaning up trunk (and after that, you
pretty much end up where the rewrite is now).
Good point indeed. I am curious; I think to remember that your coverage
report was at about 39% - I assume you did it for rewrite. Since I did
the same for DrTrigonBot framework, which is essential pywikipedia with
trunk some additional code, and had a coverage of about 40%. So what am
I missing here? Since it looks to me that there are pretty much the
same tests...?!?
For the same reason you block features after releasing
a version:
because new features introduce bugs. However, we might want to
distinguish between the framework and bots here - it should be OK
to add features to bots, as the rewrite did not clean up those
parts (and adapting these few features should not be a huge
issue).
Does this mean currently we have feature block in rewrite but not in
trunk? Are the treated different?
Yes. However, non-API functions (e.g. Special:Export
or XML) should
not go into the APISite class but in the, say, ClassicSite and
XMLSite class.
That are really good news to me! Thanks! :))
(last I heared was that API calls will be supported only in rewrite...
or... may be I was "miss-hearing"... ;)
Why would there be 'features in trunk that never
ever make it into
rewrite'? The entire point of the rewrite was to be able to have
features implemented cleanly, where every feature in trunk is
currently a hack.
So this means all features in trunk are continously ported rewrite in
order to catch up?! Which would be good news, since then some time in
future we all can easily (more or less I think) convert to rewrite!
Greetings
DrTrigon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org/
iEYEARECAAYFAk9RNg8ACgkQAXWvBxzBrDDNWQCcD6T3gpAmh1y+C4z5ytRtysht
Y8oAoKZCw2Ryr3hZI7U4ndU+6DvLAjzH
=mRIp
-----END PGP SIGNATURE-----