Re: [tor-dev] Marker branch for current tor release(s)
Hi, Tor branches are a question for tor-dev@, I am directing all responses there. Also, I fixed the top-post.
What do you mean by "alpha" and "stable" ? When tor 0.3.2.9 is released next week, there will be no alpha version. When this happens, do you want master, or the latest stable? When there are multiple supported tor versions, which one should be stable? At the moment, we support 0.2.5 and 0.2.9 as long-term support, and 0.3.0 and 0.3.1 as regular releases. Should stable be 0.3.1 (and change to 0.3.2 next week)? Do you want a long-term support branch as well? Should it be 0.2.5 or 0.2.9?
If you want something that's easier to scrape, and signed, check for new source releases at: https://dist.torproject.org/ We provide the latest Tor Browser version through a URL (which I can't remember right now). Maybe we could do the same thing with Tor.
No, you don't need Tor: $ curl http://197.231.221.211:9030/tor/status-vote/current/consensus-microdesc | grep server-versions | tr "," "\n" | tail -1 0.3.2.8-rc Or you can do this far more reliably in Python using stem: https://stem.torproject.org/
Maybe also publish in a DNS TXT record or something?
Is that secure? Can you sign a TXT record? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
(Earlier reply has somehow vanished...) On Mon, 08 Jan 2018 00:49:16 +0000, teor wrote: ...
The newest/highest, probably. Essentially the one also proclaimed as stable on the source download page.
Should stable be 0.3.1 (and change to 0.3.2 next week)?
Yes.
Do you want a long-term support branch as well?
No. I just need one version to build a relay. ...
If you want something that's easier to scrape, and signed, check for new source releases at:
Scraping would be a fallback. ...
$ curl http://197.231.221.211:9030/tor/status-vote/current/consensus-microdesc | grep server-versions | tr "," "\n" | tail -1 0.3.2.8-rc
Basically current would be the highest non-rc on the list, and alpha would be the -rc (or current if no -rc present). Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
We also tag releases with "alpha", so these should be included in the alpha branch as well. Is there any reason you can't use the source tarballs for this? They are signed, unlike git branches. https://dist.torproject.org/ T
(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? It would help some relay operators. And it would also help us get more alpha testing: https://trac.torproject.org/projects/tor/ticket/24994#comment:4 Because the experimental deb repos on this page are tied to a particular release of Tor: https://www.torproject.org/docs/debian.html.en
I was just told about the previous thread and ticket for this feature: https://lists.torproject.org/pipermail/tor-dev/2015-March/008582.html https://trac.torproject.org/projects/tor/ticket/14997 weasel wrote:
Has the reasoning changed?
If there will be a canonical alpha release branch in git, a debian repo based on that might happen more likely? (like the debian repo following master) -- https://mastodon.social/@nusenu twitter: @nusenu_
On Wed, Jan 24, 2018 at 4:02 AM, teor <teor2345@gmail.com> wrote:
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. -- Nick
On Wed, 24 Jan 2018 10:42:42 +0000, Nick Mathewson wrote: ...
You don't want force-pushes to anything but 'current' and 'alpha', and to make that policy clear. E.g. git.git itself has a branch 'pu' that does forced updates daily, as some topic branches are re-merged onto the current master (or similar) and republished as that 'pu'. That branch just serves as a means to show some current state; and master etc. don't get force-pushed. The 'weird merges' way is sufficiently weird that I rather not have a 'current' that have a weird 'current'. :-) ...
Also a way, would be good for me. I was already thinking of setting up a github repo that is a mirror of https://git.torproject.org/tor.git plus the 'current' and 'alpha' branches, but such a thing wouldn't get any blessing or traction. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
participants (4)
-
Andreas Krey -
Nick Mathewson -
nusenu -
teor