Meta framework versioning and integration semantics

[hellkite500]

NextGen consists of a several moving parts each with standalone development and versioning semantics. In order to know what parts are compatible when integrated and used together, some semantic versioning of the meta framework would be quite useful. Here is a proposed scheme for versioning:

Each repository related to NextGen maintains its own versioning and releases based on whatever that project decides/needs, but when a component is tested in the larger NextGen context and shown to work, it can apply a Git tag to its history indicating the semantic framework version it is compatible with, this might look like

tag: meta-alpha-0.1
for a component tested with other NextGen components at the meta alpha-0.1 release
The project could have its own tags/releases without the meta prefix for tracking its own history and release/state, e.g.

tag: beta-0.2 -- component released version beta-0.2

The "trick" here is likely defining the semantic bumps in the meta framework version -- what constitutes non-breaking changes? I would say initially that can simply be when any component or combination of components is "updated" to newer component versions but the overall system still integrates (at least technically) without breaking another component.

Major version changes would bump when a component/s change in such a way that other components break without their own changes to make them compatible. No these changes could be done in conjunction and joined into a minor meta release, or if done independently, maybe this constitutes a major bump?

I don't have all the answers at the moment, but wanted to put this thought down and invite discussion/ideas about how this may be implemented, used, and/or helpful!

[aaraney]

Thanks for starting the conversation, @hellkite500. Like you mentioned, I don't have the "answer" either, but this high value topic IMO.

At face value, i'm not thrilled with, for example, a BMI module repo adding a meta-alpha-0.1 tag to their repo index to indicate compatibility. It feels a little backwards to me. I agree that we need so way to indicate that a BMI module is compatible with x.y.z of the NextGen framework similar to how you might specify a dependency. I guess to me that feels like it should live somewhere else other than in a git tag name. Perhaps, a manifest file or machine usable format put in a github release? I tend to like the idea of a manifest file since it is github agnostic and more easily validated (this could be a CI stage).