3 ms·

I understand your reasoning, but I'm just a bit afraid that you won't get enough testing like this. As we know by now, even pre-releases with release notes don'

by pilif 16y ago

I understand your reasoning, but I'm just a bit afraid that you won't get enough testing like this. As we know by now, even pre-releases with release notes don't get tested enough, often forcing a quite early point release. By making the testing base even smaller than what it would anyways be, you'll lose even more bug reports. I'm sure though, you weighted in both the advantages of both systems before going this route, so that's fine. On a positive note: My huge webapp runs fine with 1.4.3-rc1 :-)

jeresig 16y ago
It is absolutely true that after a release there is, at least, some number of bug reports that pop up (regressions, browser issues, etc.). Having a pre-release helps to mitigate a lot of that. In our experience it appears as if the vast majority of the big bugs are found by the power users during the pre-release. We've tried a number of strategies to try and engage a larger audience - but at the end of the day the only thing that seems to work is actually releasing the code (we have to remember that many of the causal jQuery users are likely scared to try something that isn't a final release - either due to time or lack of interest). While we would love a 100% bug-free release - it doesn't seem to be feasible (although the increasing test coverage is certainly cutting down the total number of edge cases that we don't know about). At the time of this comment we're getting around 4.5m unique visitors to the jQuery site every month - getting a small fraction of that to test a pre-release is more than enough to cover most of the potential problems and make for a good release at the end of the day.