Opened 6 years ago

Closed 6 years ago

#9553 closed enhancement (fixed)

Please bump tor version in maint-* branches as part of the release process

Reported by: karsten Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: weasel Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I just spent an hour wondering why Shadow simulates tor-0.2.4.16-rc just fine, but aborts when simulating maint-0.2.4:

0:0:22:976412 [thread-0] 0:5:2:381227791 [scallion-error] [exit8-81.1.0.0] [scalliontor_logmsg_cb] int connection_cpu_process_inbuf(connection_t *)(): Bug: /home/ubuntu/src/shadow/build/tor/src/or/cpuworker.c:313: connection_cpu_process_inbuf: Assertion rpl.magic == CPUWORKER_REPLY_MAGIC failed; aborting.
        **aborting**

Turns out there's no bug in tor. The problem is that Shadow looks at Tor's version string in configure.ac to decide what code changes to apply. maint-0.2.4 says it's version 0.2.4.10-alpha-dev. Editing the version string in configure.ac to 0.2.4.16-rc-dev fixes the problem.

Would it be possible to bump the tor version in maint-* branches as part of the release process? Is there a document where this step should be mentioned, and do you mind me requesting an update if the version string doesn't get updated in the future?

Child Tickets

Change History (12)

comment:1 Changed 6 years ago by arma

You should be using the release-0.2.4 branch if you want to run what we're releasing.

One of the main points of using a release-0.2.4 branch rather than maint-0.2.4 is to *not* have to mess with the version in maint-0.2.4, because then every time we merge maint-0.2.4 to master we would have to manually resolve the conflict.

comment:2 Changed 6 years ago by nickm

That said, bumping the version in maint-0.2.4 and manually resolving the conflict through careful use of "merge -s ours" is not very hard; it's what I do for Libevent.

The main point where we were running into trouble when we decided to use the current system was in ChangeLog conflicts.

comment:3 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-final

comment:4 Changed 6 years ago by robgjansen

I assume my method of checking the Tor version is sane. IFF I should be doing it differently, please let me know.

FYI, there are only [currently] 3 cases where Shadow needs to do things differently depending on the Tor version:

-main-loop functionality (refill callbacks and once-per-second callbacks)
-shadow has a custom 'cpuworker' replacement, so the cpuworker protocol matters
-Tor log messages are sent to Shadow's log system, so the logmsg_cb function signature (parameter to 'add_callback_log') matters

comment:5 Changed 6 years ago by nickm

This wouldn't be so hard to do if we decide to do it. We'd want something to note that the version is later than the corresponding version in the release branch. That's best done with an extra release tag, like the "-dev" we do on the master branch between releases.

It's an extra 2-3 minutes of effort per release. Does anybody foresee it causing any problems?

comment:6 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.4.x-final

Andrea and I like the idea, if nobody else sees a problem with it.

comment:7 Changed 6 years ago by nickm

Resolution: implemented
Status: newclosed

Trying this with 0.2.4.22; maint-0.2.4 is now "0.2.4.22-dev". Documented this in doc/HACKING.

comment:8 Changed 6 years ago by arma

Resolution: implemented
Status: closedreopened

You didn't merge this from maint-0.2.4 to release-0.2.4, so now weasel's jenkins is failing to build its 0.2.4 debian packages.

I suggest clarifying in HACKING that you should merge it both to master and also release-0.x.y.

comment:9 Changed 6 years ago by arma

weasel's release process was roadblocked by this bug, so I just did what might have been the required merge. Somebody should check to see whether I destroyed the world.

comment:10 Changed 6 years ago by arma

I think there's a good argument for -s theirs rather than -s ours in this case, so the -dev version gets into release-0.2.4, and it's actually maint-0.2.4 where we bump the version for the new release, and then forward-merge that into release-0.2.4.

But I'm going to let Nick decide that. It didn't do it that way in my emergency hack.

comment:11 Changed 6 years ago by nickm

Cc: weasel added

To be clear, the problem was "weasel's scripts require that maint merge cleanly into release?" Or something else?

comment:12 Changed 6 years ago by nickm

Resolution: fixed
Status: reopenedclosed

29f2f7ce9af19f22187098fad6d002a6e5a46479 should have a better explanation of what to do now.

Note: See TracTickets for help on using tickets.