repository structure about o2r-bagtainers

[nuest]

The thing is that in this repo, I want all the different version to be there to be able to track how we got to the "standardized" version... but I see your point, I could also track that by looking at the history.

What do you think about..

• adding a tag v1, changing all occurences of "bagtainer version" to 1.
• changing all repositories to follow the structure "without /container directory" (this is work that I'd like to avoid... but might be worth it)

[JanKoppe]

I'm leaning towards GitFlow. This would solve the problem of parallel bagtainer development. Working Bagtainers, or "versions" we would like to save (as we do now with folders) would get released tagged as v0.x (e.g. 0005 → v0.5), leading up to our final standardized version of v1.0.

Changing all repositories to the new folder structure would destroy the ability to track the evolution of bagtainers, thus should be avoided.

Switching to feature branches or tagged releases would make it possible to easily differentiate travis builds and define a simpler, atomic travis configuration that only focuses on this one version of a Bagtainer, instead of trying to cover every possible version we came up with.

[nuest]

The thing is that 0001 and 0002 are not versions of bagtainers but have completely different contents. 0005 is the identifier of the bagtainer and has nothing to do with the version used in it.

[JanKoppe]

Aah, okay. In that case, the developed Bagtainer standard version should be applied to all different Bagtainers (0001 … ). Commits that change this version should then be tagged with v0.x.

But, this leads to the question: How much of the content of Bagtainers is really individual? Do we really need 10+ different example Bagtainers? iMO everything but the source data and the individual Bagtainer.yml should be included in the Bagtainer standard. Furthermore a repository split between Bagtainer standard and Bagtainer examples should be made.

Maybe I'm thinking too complicated or too far ahead, but the current structure seems very limited and not sustainable in the future.

[JanKoppe]

This Issue has been resolved verbally. We will continue with the current structure.