On Wed, Jan 24, 2018 at 4:02 AM, teor teor2345@gmail.com wrote:
(I dropped tor-relays, we can tell them when we reach a conclusion.)
Hi Nick,
Can we maintain an "alpha" branch with the latest Tor alpha, and a "stable" branch with the latest Tor stable?
Hm. I'm not strictly opposed to the idea, but I'd like to think about how it would work. The history of such branches would get pretty convoluted. While everything released from master precedes other stuff released from master in history, the releases that we cut from release-0.x.y don't precede releases in other series. So we'd either need to do force-pushes or weird merges here. And we really really don't want to have force-pushes in the canonical repo.
I'm also wondering about tags here: If we do the force-push route, then tags stay simple. But if we do the "weird merges" route, we'd not actually be giving the actual tagged versions of the releases, which suggests a downgrade.
One possibility is more structured tags: whenever a release becomes the latest stable, we could tag it "latest-stable-YYYYMMDD"; whenever a branch becomes latest alpha, we could tag it "latest-alpha-YYYYMMDD". That would make it easy to automatically find the latest release (git tag | grep ^latest-alpha | tail -1), but not require any force-pushes or weird history.
Another possibility here: what if instead of using separate branches for this, we used a separate repository, and said "this repository will get force-pushes; it's only meant for tracking releases." That way we could keep our git history clean, and keep force-pushes out of the official repo.