The important factor is the runtime. There are three "main" versions now:
v1.0.3705, usually called "1.0", v1.1.4322, usually called "1.1", and
v2.0.50727, usually called "2.0".

The framework, on the other hand, is the combination of the runtime and the
base class libraries. The .NET Framework 1.0 is the combination of the
v1.0.3705 runtime with the 1.0 BCL, 1.1 is v1.1.4322 with the 1.1 BCL, and
2.0 is v2.0.50727 with the 2.0 BCL.

So far, so good. From this point on, however, things start to diverge. .NET
3.0 is the v2.0.50727 runtime with the 3.0 BCL (which is the 2.0 BCL with
additional assemblies) while .NET 3.5 is the v2.0.50727 runtime with the 3.5
BCL (which, indeed, is the 3.0 BCL with additional assemblies) and updated
compilers to support the new languages (C# 3 being the most prominent).

Usually, not very. There are incompatibilities, but they're minor, and
usually well-documented. If you're concerned, it's always possible to force
the code to run on the exact version of the framework it needs, through its
.config file. Microsoft tries its best to break things as little as
possible, and when it does break you can always force use of the "correct"
runtime. Of course, a better long-term solution is to future-proof your
application. Usually, the changes are fixes, and there is a better way of
doing the same thing even in the older runtime.

OK, if you can bear with me, there's one more small detail I haven't
mentioned: service packs. These only update the build number, which you can
check with mscorlib.dll in the framework directories: .NET 2.0 RTM is
2.0.50727.42, .NET 2.0 SP1 is 2.0.50727.1433. These are only intended to fix
things that really can't wait for a new runtime version, and they are
intended to be good and necessary for every application using the existing
runtime (so you can't opt out).

Occasionally. The changes between 1.x and 2.0 are much bigger, from a
runtime perspective (assembly formats, finalization, garbage collection, app
domain handling, a whole lot got upgraded), even though most changes do not
visibly affect applications. The most obvious change for developers is the
fact that in 1.x, unhandled exceptions would be silently swallowed. In 2.0,
unhandled exceptions terminate the application. This is generally a good
thing and an opportunity to fix a broken application. There is a switch to
make 2.0 behave like 1.x in this regard, however.

If you've followed my little lecture so far, you should realize that there
are none whatsoever, because there are no 3.0 or 3.5 runtimes -- .NET
Framework 2.0, 3.0 and 3.5 all share the same runtime, and they have the 2.0
BCL in common. (Disclaimer: I believe things are slightly different for the
.NET Compact Framework, which does have a separate 3.5 runtime -- don't ask
me for details, though.)

In fact, 2.0 applications can reference and use 3.0 and 3.5 assemblies just
fine (I recently wrote a WCF application with VS 2005). So until CLR 3 comes
out, we're good. :-)