a collaborative lifecycle using git, where contributions are progressively integrated in a common repository
a release lifecycle where a repo at a particular moment is made available to a community, usually with a version number possibly on a package repository.
It seems to make sense to also think about packaging content units when they are part of the same release cycle, and would benefit from being tagged with a version number, for instance to update clients that use the content package. This seems that it would be a building block of a technical approach to content reuse, where content packages would be collaboratively maintained and reusable.
I think there's a lot to learn from OFK's Data Packages which recently hit 1.0.
I've done some basic implementation piggy backing on the npm registry for safetag with:
A docsmithfeature which automates npm to download the latest package.
A content.yml description which contains content package dependencies for a particular project.
Software libraries and projects both have:
It seems to make sense to also think about packaging content units when they are part of the same release cycle, and would benefit from being tagged with a version number, for instance to update clients that use the content package. This seems that it would be a building block of a technical approach to content reuse, where content packages would be collaboratively maintained and reusable.
I think there's a lot to learn from OFK's Data Packages which recently hit 1.0.
I've done some basic implementation piggy backing on the npm registry for safetag with:
docsmithfeature which automates npm to download the latest package.content.ymldescription which contains content package dependencies for a particular project.Some open questions and directions of work are: