Sure, mistakes happen, and sometimes it's our fault. But the point is Apple's policies turn what would normally be a routine bug fix in to a total nightmare.
The suggestions as to what Apple could do to help are all great, but it does look (from here) like there could be ways to tweak application development process to better shield against breakage.
It might seem like I’m stating the obvious, but I really do think it could be worth spending time with the preview releases.
I assume the reason this isn’t done is as pointed to in the article - a lack of correlation between what goes into a preview release and what ends up in a real release, but is it really the case that none of the three issues raised could have been avoided if they had been spotted slightly earlier?
The first looks like it was a case of over reliance on what was communicated by Apple. “Trust but have a backup plan” would seem like a useful approach here, if it is reasonable to consider the option of enlisting or creating a compatible replacement for using the Javascript zip library.
The second issue - reliance on a bug - just seems like something that is easy to fall foul of, but in retrospect would it have been possible to have noticed that there was an assumption being made, or that there might be a test missing to catch a future change in behaviour?
The third sounds like an assumption in the application code (that a value would not be null) which may have been a perfectly fine thing to do, if it was going to be obvious what the issue was as soon as it broke, but…
… the description of the pain of having to put out an ‘emergency’ release gives the impression that there is scope for making this process easier. I understand, of course, that automated testing of anything that runs in a browser is still hard, so it may be that it’s this part of the release process that causes friction and the returns from improving this have already diminished as it’s been refined.
It’s such a great product and I hope there can be less friction in keeping up with Safari as it’s fantastic to see cross platform web applications continuing to thrive.
It might seem like I’m stating the obvious, but I really do think it could be worth spending time with the preview releases.
I assume the reason this isn’t done is as pointed to in the article - a lack of correlation between what goes into a preview release and what ends up in a real release, but is it really the case that none of the three issues raised could have been avoided if they had been spotted slightly earlier?
The first looks like it was a case of over reliance on what was communicated by Apple. “Trust but have a backup plan” would seem like a useful approach here, if it is reasonable to consider the option of enlisting or creating a compatible replacement for using the Javascript zip library.
The second issue - reliance on a bug - just seems like something that is easy to fall foul of, but in retrospect would it have been possible to have noticed that there was an assumption being made, or that there might be a test missing to catch a future change in behaviour?
The third sounds like an assumption in the application code (that a value would not be null) which may have been a perfectly fine thing to do, if it was going to be obvious what the issue was as soon as it broke, but…
… the description of the pain of having to put out an ‘emergency’ release gives the impression that there is scope for making this process easier. I understand, of course, that automated testing of anything that runs in a browser is still hard, so it may be that it’s this part of the release process that causes friction and the returns from improving this have already diminished as it’s been refined.
It’s such a great product and I hope there can be less friction in keeping up with Safari as it’s fantastic to see cross platform web applications continuing to thrive.