In any case, starting with 9.3 there will be no more point releases. There will be updates you can apply via the update manager, but new ISOs probably won't happen except on major release boundaries. With any luck, 9.2.1.7 will be the last point release FreeNAS users ever see. :)
I'm a little confused. In the current (ISO-based) model, it's easy to roll back to the previous version if there's a problem with an upgrade. How will rollbacks work under the new model?
Also, how will we be able to update file servers that aren't connected to the Internet? Even the documentation notes that "In many cases, a FreeNAS® configuration will deliberately exclude default gateway information as a way to make it more difficult for a remote attacker to communicate with the server."
Will every new install have to download a bunch of additional patches as soon as it starts up?
You're thinking old-school. When a user installs OS X "Mavericks" (and the use of a name vs an arbitrary number is intentional) they don't think about point releases. They install something with a name, and then when the update app says "Hi, we have updates for you" they just indicate their willingness to apply them (or not). ... we don't want users having to know or care which "point release" they're running anymore, just that they're up-to-date. That's the value of not having point releases. To anyone who's not a developer or skilled with git, they don't have any real meaning.
Perhaps I'm misunderstanding, but that seems a strange example to use. Apple does in fact release point releases.
Yes, they release interim updates to various components, but then they release a point release that rolls up interim changes into a single (presumably well-tested) package. That's why they're up to 10.9.4 and testing 10.9.5. I go to "About this Mac" and right under the "Mac OS X" title, it says "10.9.4". In the App Store it says the current version is 10.9.4.
And even git has the notion of "tags" so that it's clear when something is released.
I can definitely imagine some benefits to allowing individual components to be updated more easily (and perhaps without rebooting), but I'm having a hard time seeing how more frequent updates are compatible with the notion of a stable server that changes relatively infrequently? This seems like you're inviting a configuration management nightmare.
I must be missing something, but what? What's the actual motivation for going to all this effort? The ability to verify the authenticity of packages?