[tor-dev] Marker branch for current tor release(s)

[teor]

Hi,

Tor branches are a question for tor-dev@, I am directing all responses there.
Also, I fixed the top-post.

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.

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
------------------------------------------------------------------------

[Andreas Krey]

(Earlier reply has somehow vanished...)

On Mon, 08 Jan 2018 00:49:16 +0000, teor wrote:
...

Post by teor
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.

Post by teor
Should stable be 0.3.1 (and change to 0.3.2 next week)?

Yes.

Post by teor
Do you want a long-term support branch as well?

No. I just need one version to build a relay.

...

Post by teor
If you want something that's easier to scrape, and signed, check for

Scraping would be a fallback.

...

Post by teor
$ 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

[teor]

Post by Andreas Krey
(Earlier reply has somehow vanished...)

Post by teor
...
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.

Post by teor
Should stable be 0.3.1 (and change to 0.3.2 next week)?

Yes.

Post by teor
Do you want a long-term support branch as well?

No. I just need one version to build a relay.
...

Post by teor
If you want something that's easier to scrape, and signed, check for

Scraping would be a fallback.
...

Post by teor
$ 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

[teor]

(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

Post by teor

Post by Andreas Krey
(Earlier reply has somehow vanished...)

Post by teor
...
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.

Post by teor
Should stable be 0.3.1 (and change to 0.3.2 next week)?

Yes.

Post by teor
Do you want a long-term support branch as well?

No. I just need one version to build a relay.
...

Post by teor
If you want something that's easier to scrape, and signed, check for

Scraping would be a fallback.
...

Post by teor
$ 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/

[teor]

Post by teor
(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

Post by teor
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?

Post by teor
It would help some relay operators.
https://trac.torproject.org/projects/tor/ticket/24994#comment:4
Because the experimental deb repos on this page are tied to a
https://www.torproject.org/docs/debian.html.en

Post by teor

Post by Andreas Krey
(Earlier reply has somehow vanished...)

Post by teor
...
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.

Post by teor
Should stable be 0.3.1 (and change to 0.3.2 next week)?

Yes.

Post by teor
Do you want a long-term support branch as well?

No. I just need one version to build a relay.
...

Post by teor
If you want something that's easier to scrape, and signed, check for

Scraping would be a fallback.
...

Post by teor
$ 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/

[nusenu]

Post by teor

Post by teor
Can we maintain an "alpha" branch with the latest Tor alpha,
and a "stable" branch with the latest Tor stable?

https://lists.torproject.org/pipermail/tor-dev/2015-March/008582.html
https://trac.torproject.org/projects/tor/ticket/14997

Post by teor
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)

[Nick Mathewson]

Post by teor
(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.

[Andreas Krey]

On Wed, 24 Jan 2018 10:42:42 +0000, Nick Mathewson wrote:
...

Post by Nick Mathewson

Post by teor
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'. :-)

...

Post by Nick Mathewson
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