[question] Why are versions tracked with branches rather than tags?

[steve-thousand]

I am trying to understand the system used to mark releases. I have been unable to find any documentation or github issue that addresses my questions of how branches should be used.

I found this issue which suggests that there is a preferred convention for branches but am unclear what that is https://github.com/bincrafters/community/issues/828

It looks like most bincrafters conan repositories use branches to track work for different versions as well as different channels, ie. separate branches for "stable/1.0.0" vs "stable/1.2.0" vs "testing/1.2.0". Once these versions have been released, does the persistence of the branches serve a purpose? Is there a convention for telling when a channel/version was officially "released"? Do all branches necessarily merge back into a default branch?

[Croydon]

Your question all aiming at git repositories that hold one recipe.

Once these versions have been released, does the persistence of the branches serve a purpose?

Yes, like the entire idea of git, being able to go back in time to understabd changes and decisions is important. Moreover, the version numbers are the versions of the software we do package.

As an example: For SDL2 it would be sdl2/2.0.12@bincrafters/stable. So you will find there branches like testing/2.0.12 and stable/2.0.12. testing branches only exist in git and runs the test in CI, but they won't get published in the Conan remote. Once the git commits with the recipes are pushed to a stable branch, they get published in the Conan remote.

Let's say we have initially published a sdl2/2.0.12@bincrafters/stable package and later on we find a bug or want to improve the recipe. In that case, we apply the changes, commit it and push it. First to testing, if everything looks good later to stable.

This works with branches, but would not work with git tags as tags are supposed to be a frozen, concrete target.

I found this issue which suggests that there is a preferred convention for branches

The default branches in the repositories are the testing branches with the largest version number.

Do all branches necessarily merge back into a default branch?

There is no permanent default branch as the default branch changes with each new version of the software we package. New versioned branches are almost always based on the currently latest branches and therefore contain its commits up the point of time of its creations. That said, no, there is no general merging of everything into a specific branch.

Please note that all of this information only applies to git repositories that hold a single Conan recipe (in different versions). This is a workflow we are currently phasing-out and replacing with a monolithic repository workflow, i.e. a single git repository with many different Conan recipes. Have a look in this very repository to check that out (the community repo). Here we do have a default branch in which everything gets merged and all testing happens in pull requests.

[steve-thousand]

Thanks so much for the quick and thorough response!

Given that conan recipes are mutable, it makes sense then that tags would not work. I still have some outstanding questions as well as some new ones based on your feedback.

• One outstanding question that is still unclear to me is: Is there a convention for telling when a channel/version was officially "released"? Without a main branch, it is hard to determine the "entrypoint" of a version.

• Can the default branch be treated as the main branch? If I were to crawl from the latest default commit to the beginning of time, would I be crawling all commits for all stable versions?

• When someone wants to change the build options/requirements of an older stable branch, does the default branch get merged back into it? I am wondering how much drift, if any, can be expected between the various branches. That seems to be a possible downside of managing the builds as multiple branches.

• Moving towards a central index repo similar to conan-center is interesting, and I am curious how builds for different channels will be tracked in that case, because conan-center doesn't seem to use channels. Will branches still be used, or will there be a new way of tracking stable/testing builds in the community repo? Or will channels no longer be tracked?

And possibly to save you the trouble of responding, is there a place that documents the branching strategy?

[asantosca]

I'd be interested in this too @Croydon

[Croydon]

One outstanding question that is still unclear to me is: Is there a convention for telling when a channel/version was officially "released"? Without a main branch, it is hard to determine the "entrypoint" of a version.

Beyond going through the git history and looking for commits along the lines of "update to/add x.y.z" not really. On the server side, Conan is saving a timestamp for Conan revision, but I'm not sure if this could be easily gatherd by Conan clients.

Can the default branch be treated as the main branch? If I were to crawl from the latest default commit to the beginning of time, would I be crawling all commits for all stable versions?

No, since every recipe for every version can be updated even after there is already a recipe for a newer version. There is no real reason why commit specifically for an older version should be merged into a branch for a newer version when it does not apply for it

When someone wants to change the build options/requirements of an older stable branch, does the default branch get merged back into it?

Not necessary.

I am wondering how much drift, if any, can be expected between the various branches. That seems to be a possible downside of managing the builds as multiple branches.

Yes, there are many downsides, that is also the reason why we moving away from this workflow

Moving towards a central index repo similar to conan-center is interesting, and I am curious how builds for different channels will be tracked in that case, because conan-center doesn't seem to use channels. Will branches still be used, or will there be a new way of tracking stable/testing builds in the community repo? Or will channels no longer be tracked?

Testing packages were never uploaded and only existed in git and temporarily in the CI systems. Instead of using explicit testing/ branches, they are now any non-main branch or branches from outside contributors. The main branch serves now as the (only) stable/ branch.

And possibly to save you the trouble of responding, is there a place that documents the branching strategy?

No clear documentation about this unfortunately.