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.
On Jan 5, 2018 00:48, "Andreas Krey" <a.krey@gmx.de> wrote:
https://www.torproject.org/download/download.html.en in the source code 'tab' states the current stable and alpha version of tor.
Would it be possible to publish the current states as branches 'stable' and 'alpha' (or 'testing', or 'unstable') in the git repo?
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?
That would help us tor-from-source builders to just fetch the repo, and if the respective branch changes, to rebuild and redeploy. Looking for a new release tag or screen-scraping said web page is a bit hairy, and feels unnecessary.
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.
On 5 Jan 2018, at 23:17, Chad MILLER <chad@cornsilk.net> wrote:
I second this.
There's a recommended-versions list in the consensus, but you have to already have Tor available and running to get it.
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: ...
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.
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
On 13 Jan 2018, at 08:07, Andreas Krey <a.krey@gmx.de> wrote:
(Earlier reply has somehow vanished...)
On Mon, 08 Jan 2018 00:49:16 +0000, teor wrote: ... 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.
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).
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
On 13 Jan 2018, at 09:06, teor <teor2345@gmail.com> wrote:
On 13 Jan 2018, at 08:07, Andreas Krey <a.krey@gmx.de> wrote:
(Earlier reply has somehow vanished...)
On Mon, 08 Jan 2018 00:49:16 +0000, teor wrote: ... 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.
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).
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.
On 24 Jan 2018, at 20:02, 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?
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:
Running the current alpha should always be a deliberate decision. If you can't be bothered to change your sources.list once or twice a year, then you probably should be running stable.
Has the reasoning changed?
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
On 13 Jan 2018, at 09:06, teor <teor2345@gmail.com> wrote:
On 13 Jan 2018, at 08:07, Andreas Krey <a.krey@gmx.de> wrote:
(Earlier reply has somehow vanished...)
On Mon, 08 Jan 2018 00:49:16 +0000, teor wrote: ... 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.
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).
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.
Can we maintain an "alpha" branch with the latest Tor alpha, and a "stable" branch with the latest Tor stable? 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:
Running the current alpha should always be a deliberate decision. If you can't be bothered to change your sources.list once or twice a year, then you probably should be running stable. 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:
(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. -- Nick
On Wed, 24 Jan 2018 10:42:42 +0000, Nick Mathewson wrote: ...
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.... And we really really don't want to have force-pushes in the canonical repo.
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'. :-) ...
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."
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