3 ms·

I don't see the point in doing so - the important part is getting some developers to put the copy of jQuery into their page to see if there are any regressions.

by jeresig 16y ago

I don't see the point in doing so - the important part is getting some developers to put the copy of jQuery into their page to see if there are any regressions. Additionally we provide focus on the general areas of the library that had major changes. There's actually a lot of concern with making the pre-releases too enticing to end users. If we make it appear as if it's a completed release (it's not) then user's will be more likely to try and use it as if it were - and that will certainly cause problems. We want to make sure that after this testing phase is complete we never have to hear about another jQuery 1.4.3rc1-related bug, again. Note that the release was also done at about 11:30pm on a Sunday night before a U.S. holiday. We actually want to make sure that we're hitting a minimum of the full jQuery audience - just enough of the power users to dig in and see if any regressions occurred - without saturating the full jQuery userbase.

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.

by jeresig 16y ago

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.