It's only necessary to do this when field changes are made. In fact,
only when there's some nontransient field foo in the old version and
in the new version it's missing or it's of a more specific type or its
semantics are changed. Generally this means you renamed or deleted a
field, changed it to be of a subclass of whatever it used to be (e.g.
from Collection to List, or List to ArrayList), or changed the
semantics (e.g. double x, y, z used to be interpreted with z being
"up", and now is interpreted with y being "up", or vice-versa).

So when fields recorded basically as name=value pairs are read back in
there'd be nowhere for one to go, or a ClassCastException, or it would
seem to work but something would break further down the line.

Adding a field that can tolerably be left false, zero, or null when
old objects are read back in isn't a problem. If the added field
should have a sensible content, though, and old objects won't work if
this new field is left blank, change the version number.

There's some way of supporting older versions with explicit readObject
methods but you rarely want to.