Return to Answer

The granularity of those version numbers should match the granularity of the serialization units.

The purpose of version numbers in serialized data is to allow the detection of structural and semantical changes in those classes between the time when the data was serialized and the time when it gets deserialized (and apply a proper migration process in case it is required).

So ask yourself: do you serialize / deserialize all objects of your lib into one file? Then the version number from the lib will be sufficient as the version of that file. Or do you serialize / deserialize each object into its own file? Then you will probably require one version number per class.

Of course, the file metapher is just a helpful thought model - the important thing is the granularity of your migration process during deserialization, specifically in case the version numbers of the current classes in code doesn't match the version number stored in the serialization file. Will your requirements allow to migrate serialized data of individual classes to a newer version? Or will they only allow a migration "all at once"?

(Side note: please do yourself a favor and stop thinking in "best practices" or "common patterns". Better ask yourself what requirements you have and what approach will support those requirements best.)

The granularity of those version numbers should match the granularity of the serialization units.

The purpose of version numbers in serialized data is to allow the detection of structural and semantical changes in those classes between the time when the data was serialized and the time when it gets deserialized (and apply a proper migration process in case it is required).

So ask yourself: do you serialize / deserialize all objects of your lib into one file? Then the version number from the lib will be sufficient as the version of that file. Or do you serialize / deserialize each object into its own file? Then you will probably require one version number per class.

Of course, the file metaphor is just a helpful thought model - the important thing is the granularity of your migration process during deserialization, specifically in case the version numbers of the current classes in code doesn't match the version number stored in the serialization file. Will your requirements allow to migrate serialized data of individual classes to a newer version? Or will they only allow a migration "all at once"?

(Side note: please do yourself a favor and stop thinking in "best practices" or "common patterns". Better ask yourself what requirements you have and what approach will support those requirements best.)

The granularity of those version numbers should match the granularity of the serialization units.

So ask yourself: do you serialize / deserialize all objects of your lib into one file? Then the version number from the lib will be sufficient as the version of that file. Or do you serialize / deserialize each object into its own file? Then you will probably require one version number per class.

Of course, the file metapher is just a helpful thought model - the important thing is the granularity of your upgrade (or "migration") process during deserialzation, specifically in case the version numbers of the current classes in code doesn't match the version number stored in the serialization file. Will your requirements allow to migrate serialization data of individual classes to a newer version? Or will they only allow only a migration "all at once"?

(Side note: please do yourself a favor and stop thinking in "best practices" or "common patterns". Better ask yourself what requirements you have and what approach will support those requirements best.)

The granularity of those version numbers should match the granularity of the serialization units.

The purpose of version numbers in serialized data is to allow the detection of structural and semantical changes in those classes between the time when the data was serialized and the time when it gets deserialized (and apply a proper migration process in case it is required).

So ask yourself: do you serialize / deserialize all objects of your lib into one file? Then the version number from the lib will be sufficient as the version of that file. Or do you serialize / deserialize each object into its own file? Then you will probably require one version number per class.

Of course, the file metapher is just a helpful thought model - the important thing is the granularity of your migration process during deserialization, specifically in case the version numbers of the current classes in code doesn't match the version number stored in the serialization file. Will your requirements allow to migrate serialized data of individual classes to a newer version? Or will they only allow a migration "all at once"?

(Side note: please do yourself a favor and stop thinking in "best practices" or "common patterns". Better ask yourself what requirements you have and what approach will support those requirements best.)

The granularity of those version numbers should match the granularity of the serialization units.

So ask yourself: do you serialize / deserialize all objects of your lib into one file? Then the version number from the lib will be sufficient as the version of that file. Or do you serialize / deserialize each object into its own file? Then you will probably require one version number per class.

Of course, the file metapher is just a helpful thought model - the important thing is the granularity of your upgrade (or "migration") process during deserialzation, specifically in case the version numbers of the current classes in code doesn't match the version number stored in the serialization file. Will your requirements allow to migrate serialization data of individual classes to a newer version? Or will they only allow only a migration "all at once"?

(Side note: please do yourself a favor and stop thinking in "best practices" of "common patterns" - better ask yourself what requirements you have and what approach will support those requirements best.)

The granularity of those version numbers should match the granularity of the serialization units.

So ask yourself: do you serialize / deserialize all objects of your lib into one file? Then the version number from the lib will be sufficient as the version of that file. Or do you serialize / deserialize each object into its own file? Then you will probably require one version number per class.

Of course, the file metapher is just a helpful thought model - the important thing is the granularity of your upgrade (or "migration") process during deserialzation, specifically in case the version numbers of the current classes in code doesn't match the version number stored in the serialization file. Will your requirements allow to migrate serialization data of individual classes to a newer version? Or will they only allow only a migration "all at once"?

(Side note: please do yourself a favor and stop thinking in "best practices" or "common patterns". Better ask yourself what requirements you have and what approach will support those requirements best.)