This this expected behavior per OSGi spec, you need refresh bundle DEF to ensure the changes take effect.
Here is how it works under the hood.
If the snapshot bundle you're updating still used(such as import package) by other bundles. Let's say the snapshot bundle is bundle A, and another bundle B import package from Bundle A. So the scenario is that
Before you update Bundle A, in OSGi container
Bundle A in Revision1<============Bundle B in Revision1
After you update Bundle A, in OSGi container
Bundle A in Revision1<============Bundle B in Revision1 and there's also a Bundle A in Revision2(so here in the OSGi container two revisions for BundleA, but only Revision1 take effect)
at this moment Bundle B in Revision1 still refer the Bundle A in Revision1, you need explicitly refresh Bundle A which in turn will cause all other bundles use(and transitively use) Bundle A to re-resolve(this operation is really heavy loaded work as so many bundles might be resolved again, it depend on if BundleA play a very basic bundle role), after that the new revision2 for BundleA take effect.
So after you refresh BundleA, in OSGi container,
Bundle A in Revision2<============Bundle B in Revision1
At this moment you changes for that snapshot BundleA take effect.
This kind of two-steps update/refresh operation avoid unnecessarily frequently resolving lots of bundles(as it's cpu consuming task), you can updated several bundles and then refresh once to get all changes take effect as one goal, and this behavior is totally from OSGi spec.
The different scenario is that if the SNAPSHOT Bundle A is self-used, no other Bundles import package or OSGi service from Bundle A, then update BundleA means the new revision will take effect immediately.
Hope this helps