#241: Thorns should be able to specify implementation versions, and other thorns should be able to depend on those --------------------------+------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by hinder):
I don't like version numbers because they impose a linear structure, and we sometimes have different branches (both explicitly in the repository, and implicitly with locally applied patches).
What about saying that thorns provide certain "features", and other thorns require these features? We might even consider re-using the capabilities mechanism for this, though it is a low-level technical detail and maybe best not exposed to the user. For example, for the recent READS/WRITES changes to the flesh, we could say that the flesh now supports READS_WRITES, and thorns could declare that they need READS_WRITES. If the flesh does not support it, the user gets an error message saying that they need a (probably newer) version of the flesh which supports READS_WRITES.
This is relevant now because if we merge some of the development branches of Kranc into master and regenerate McLachlan, a very recent flesh will be needed for the READS/WRITES support.
Do we want to depend on features/versions of "implementations" or of "capabilities"?
Rather than adding new capabilities, maybe we could make these parameters of the capability. For example, we could depend on Cactus{READS_WRITES,...}. Maybe every so often we could bundle these capabilities up into a version number, perhaps corresponding to a release.