Paul wrote:
> I do feel we may be being overly cautious, and if there is scope
> leakage then it will help refactoring and plugin authors if we
> understand the problem better and have regression tests to follow.
Unfortunately, BT/Osmosoft's track record on testing is *abysmal*
Currently, there doesn't appear to be any kind of *formal* QA process
in place to test the core code. Except for individual developer's
doing their own idiomatic testing, plus a few unit tests (which are
incomplete, at best), proper "acceptance" testing before releasing a
new version into the community is simply not occuring at any level...
no regression tests, no integration tests, no cross-platform tests, no
stress tests... none.
As a result, serious (but subtle) problems are sometimes not found
until exposed to the varied use-cases 'in the wild', where they can
have an immediate "show stopping" impact on unsuspecting members of
the TiddlyWiki community that rely upon a reasonable expectation that
new releases will always be as backward-compatible as they can
possibly be.
In addition, the usual response from the core team to these show-
stopping problems has been, to say the least, extremely
disappointing. Even when a ticket has been created, very little if
anything seems to get done in the short-term to address the problem.
Typically, a ticket will sit for months and months while the folks at
BT/Osmosoft are busy working on their own "cool stuff" and plans for
where they want to take the 'future of TiddlyWiki'...
Paul wrote:
> We can work-around, and in the worst case, I still see it as the duty
> of the developer of a plugin to work-round the clash, as it would be
> if they introduced something which clashed with another existing core
> library function.
There is a BIG difference between a plugin introducing something *new*
that clashes with an *existing* core function, versus an *existing*
plugin being broken by the introduction of *new* code into a core
function.
We are not just talking about new plugin code that has yet to be
written. When a core change breaks a plugin, it's not simply a matter
of publishing an update to the plugin code to work-around the problem
(if that's even possible)...
The issue is that *existing* installed copies of that plugin will
break as soon as the documents in which they are already installed are
upgraded with the latest official core release. From the end-user's
standpoint, upgrading the core causes their *previously functioning*
TiddlyWiki documents to unexpectedly fail in very dramatic ways (hang/
errors on startup, numerous plugin/macro errors, and even tiddler data
corruption are all possible outcomes).
Among the typical users responses:
* revert to a backup copy using the previous core release, and then
*never* upgrade that document. Of course, because each TW document is
self-contained, this is always an option, but really defeats the
purpose of releasing a core upgrade in the first place... we really
want people to adopt the latest core code without hesitation, so that
support for backward-compatible deprecated/legacy code actually can
eventually be left behind... but only *after* an overwhelming majority
of the TW community has successfully moved on to the newer code
code.
* For some users, especially novices, upgrade failures will lead to
FUD (Fear, Uncertainty, and Doubt), resulting in a complete loss of
confidence in TiddlyWiki as practical solution for their information
needs. If the FUD starts to spread (e.g., via published reports of
upgrade failures), TiddlyWiki can quickly become relegated to simple
"personal/hobby" use, and lose all credibility as a serious, robust,
viable platform for production-level uses (especially commercial uses,
where even small errors can cost a lot of money!)
* for users who hang in there, finding the problems in numerous
plugins often involves a tedious trial-and-error process to reduce
complex use-cases and isolate the causes with simple, reproducible
test cases that can then be reported the individual plugin developers
in hopes that a fix will be forthcoming.
Of course, some of these developer's are no longer actively involved
with TiddlyWiki development ('orphaned code'), or are busy working on
other things ('a real job'), or don't know how to fix the problem, or
simply don't respond for other reasons. Even when a plugin developer
does respond, the amount of time and effort it takes to analyze,
diagnose, write and test the necessary changes to just one plugin can
be extensive (depending upon the complexity, of course).
For my own part, here's a little math: the core code size is currently
about 335K, and there are at least 5 core developers at BT/Osmosoft.
In comparison, the TiddlyTools codebase -- which provides enhanced
features to support *thousands* of varied use-cases, primarily written
in response to the specific real-word needs of actual TiddlyWiki
users, authors and developers world wide
-- is over 2Mb and contains nearly 200 separate plugins and scripts,
all maintained by one developer (me). Even fixing just one plugin can
take many hours/days... all just to keep existing functionality
working.
Paul wrote:
> Again I see this a quite different issue. One could argue that by
> making TiddlyWiki more open and friendly to jQuery plugins and
> developers we'll expand the TiddlyWiki community of plugin authors.
Chris wrote:
> Plugins that fail to be resilient in the face of stability in the
> public API of the core should be considered buggy. Those that rely on
> behavior in private code should be considered buggy. Otherwise the
> domain of backwards compatibility responsibility in the core becomes
> far too large: It takes on win32 proportions and there's just not that
> many core developers in the TiddlyWiki community.
> Requiring a large domain of backwards compatibility constrains
> TiddlyWiki's ability to evolve and move into the future. And
> everything has to evolve.
While that may be so, I strongly believe that the future of TiddlyWiki
will be determined not by some theoretical principles of software
architecture discussed amongst a small group of core developers and
then released upon the world as a "fait accompli". Rather, the
success or failure of TiddlyWiki as whole is entirely dependent upon
whether or not it fullfills the needs, interests and intentions of the
people who are actually *using* it. Sure, making it easier for jQuery
developers may help encourage more plugin authors, but not if it
damages the end-user experience and introduces FUD into the mix.
> I suggest we continue to use the jquery alias, build more tests for
> "$" and consider flipping to "$" once we understand the problem
> better. I think at this point adding TiddlyWiki special "jq" alias
> will make matters worse, and only add yet another thing we are
> committed to maintain for backwards compatibility.
Here's the only place we agree! I'm not 100% averse to someday using $
() instead of jQuery()... I just don't think it's *necessary* and see
it as a complication, rather than an advantage.
respectfully,
-e
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/TiddlyWikiDev?hl=en
-~----------~----~----~----~------~----~------~--~---
