Log in |
|
Developer Blog
Categories:
Announcements
(44)
Content
(56)
Copyright
(0)
Deep Code
(3)
Development
(232)
Documentation
(57)
Maintenance
(17)
Markup
(32)
Metadata
(2)
Printing
(7)
Style
(9)
Testing
(2)
Usability
(7)
|
|||||||||||||||||||||||||||||||||||||||||||||||||
Collection XML First Draft
Are we planning to keep something in the system for every composite version? It would be wasteful to keep lots of intermediate ones that no one every asked for.
I would propose the following.
X.Y where X is the collection structure version and increments at every collection publication (structure change) regardless of what the change is. The system needs a copy of the collection structure for each major version.
Y is a simple increment when any module that is specified as "latest" is republished. At the time that the module is published, if the collection is at X.Y, then the collection goes to X.Y+1 and the collection structure is modified to include X.Y+1 as its current version (collection_composite_version).
To the collection metadata add collection_composite_version -- X.Y
To each included module at 'latest' we add the following metadata bits:
1. module_version_at_collection_publish --
2. collection_version_where_this_module_republished -- list -- X.Y, X.Z etc.
From this you can reconstruct the exact module versions for any collection composite version. So for example, to reconstruct collection X.N, you retrieve collection major version X (which always corresponds to the latest composite version) and then work your way from X.1 to X.N (the desired version) incrementing module versions by looking at the "republished" list. For each list, increment the module version for each entry in the list where X.A is < or = to X.N
That won't happen very often.
Benefits -- Simple version number, always increasing, non-random, single copy of the collection structure for each major version number, can reconstruct exact module numbers for any composite version number.
Kathi