Versioning and Releases

changed milestone to %Onionoo 3.1-1.0.0

added component::metrics/onionoo milestone::Onionoo 3.1-1.0.0 owner::iwakeh priority::medium resolution::implemented severity::normal status::closed type::enhancement labels

Replying to iwakeh:

As with the Onionoo protocol the application itself needs versioning, too.

Agreed. Let's start a ChangeLog file, define the current version as 0.0.1, and add a Git tag for it. Guess I should sign the tarball and maybe also the Git tag. Anything else?

It might be a good idea to also add versions to the classpath components defined in build.xml? Also as some sort of documentation.

Like:

-      <include name="gson.jar"/>
+      <include name="gson-2.2.3.jar"/>

If yes, sure, fine by me. If not, what do you mean?

What about releases?

Sure, I just asked internally where we should make release files available. Once we have a location, we should create an Ant task to put all files belonging to a release into a tarball.

What about the metrics-lib jar? Should that be included with the Onionoo release?

Especially deployers might not be happy about having to bother with compilation before setting up an Onionoo server.

Agreed.

For development a release of metrics-lib would be useful, too.

Not sure if I agree about this one. Developers should know how to handle Git submodule, and if not, we should include a paragraph on that in the yet-to-be-written documentation. But this is related to whether we're shipping the metrics-lib jar with the Onionoo release or not.

Replying to karsten:

Agreed. Let's start a ChangeLog file, define the current version as 0.0.1, and add a Git tag for it. Guess I should sign the tarball and maybe also the Git tag. Anything else?

Oh, don't you think the Onionoo server already deserves a 1.0.0? One idea would be: The server version a.x.y could reflect the major protocol version a.b. Hence, the major version is the Onionoo protocol "edition",
the middle x will be increased for server changes like switching to an embedded server or minor protocol changes, and the final y stands for bugfixes and minor server enhancements.

Like:

{{{

```
 <include name="gson.jar"/>
```

```
 <include name="gson-2.2.3.jar"/>
```

}}}

Exactly!

What about the metrics-lib jar? Should that be included with the Onionoo release? Well, metrics-lib should have releases, too. Thus, there would be the <include name="metrics-lib-1.0.0.jar"/> line in build.xml and a place to download the jar.

All libs from the classpath or there contents would be included in a on-jar-solution (as discussed in #13089 (moved)). Including them as jars in addition is sort of nice for everyone who wants to play with the sources. On the other hand that might cause a big tarball, and only including metric-libs (b/c it is also supplied from the Tor project) is ok, or even no other jars, not even metrics-lib would work. Is there some general Tor release rule about such things?

Not sure if I agree about this one. Developers should know how to handle Git submodule, and if not, we should include a paragraph on that in the yet-to-be-written documentation. But this is related to whether we're shipping the metrics-lib jar with the Onionoo release or not.

I agree, developers have to be able to or able to learn to deal with git submodules. afaik some other projects depend on metrics-lib. To me, that is a good reason to only use a released jar in onionoo (as well as in these other projects) and not a git submodule; that'll separate development. What was the reason for the git submodule setup?

Replying to iwakeh:

Replying to karsten:

Agreed. Let's start a ChangeLog file, define the current version as 0.0.1, and add a Git tag for it. Guess I should sign the tarball and maybe also the Git tag. Anything else?

Oh, don't you think the Onionoo server already deserves a 1.0.0? One idea would be: The server version a.x.y could reflect the major protocol version a.b. Hence, the major version is the Onionoo protocol "edition",
the middle x will be increased for server changes like switching to an embedded server or minor protocol changes, and the final y stands for bugfixes and minor server enhancements.

I like the idea of protocol version and server version being connected. But why not using a single version string for both purposes? We could extend the protocol version idea and append a server version number, as in "major.minor.server". Whenever there are changes to the server that don't affect the protocol, we'll just increase the "server" part by one. We could also reflect major or minor changes to the server, as in "protocol-major,protocol-minor,server-major,server-minor", but I think that might be overkill.

Should we leave "version" field in responses unchanged and only include "major.minor"? Clients don't really care about the server version, but only about the protocol. If we wanted to write "major.minor.server" there, I think that would require a minor protocol change in itself, so switching to "1.1.0" in this case.

Thoughts?

Like:

{{{

```
 <include name="gson.jar"/>
```

```
 <include name="gson-2.2.3.jar"/>
```

}}}

Exactly!

Heh, except that we're using gson-2.1.jar, not gson-2.2.3.jar. Please try out my branch task-13088 and tell me if that works for you.

What about the metrics-lib jar? Should that be included with the Onionoo release? Well, metrics-lib should have releases, too. Thus, there would be the <include name="metrics-lib-1.0.0.jar"/> line in build.xml and a place to download the jar.

Okay, let's do metrics-lib releases, but independent from this ticket. I just created #13166 (moved) for this.

All libs from the classpath or there contents would be included in a on-jar-solution (as discussed in #13089 (moved)).

(I assume you mean "one-jar-solution"?)

Including them as jars in addition is sort of nice for everyone who wants to play with the sources. On the other hand that might cause a big tarball, and only including metric-libs (b/c it is also supplied from the Tor project) is ok, or even no other jars, not even metrics-lib would work. Is there some general Tor release rule about such things?

There are no general rules about these things, so we can make our own. Should we resolve #13089 (moved) first?

Not sure if I agree about this one. Developers should know how to handle Git submodule, and if not, we should include a paragraph on that in the yet-to-be-written documentation. But this is related to whether we're shipping the metrics-lib jar with the Onionoo release or not.

I agree, developers have to be able to or able to learn to deal with git submodules. afaik some other projects depend on metrics-lib. To me, that is a good reason to only use a released jar in onionoo (as well as in these other projects) and not a git submodule; that'll separate development. What was the reason for the git submodule setup?

Well, putting out releases causes some overhead that we tried to avoid. But I can see the advantage of having releases, so let's switch.

The "protocol-major.protocol-minor.server" versioning is a nice idea. Let's use it. Clients won't need the information about the server, they only care abot the protocol itself. So, no need to change the version field in the protocol.

Heh, except that we're using gson-2.1.jar, not gson-2.2.3.jar.

Oh, a trick question ;-) I also use gson-2.1.jar.

Please try out my branch task-13088 and tell me if that works for you. Looks good, I have exactly the same library versions as listed in this branch.

Including them as jars in addition is sort of nice for everyone who wants to play with the sources. On the other hand that might cause a big tarball, and only including metric-libs (b/c it is also supplied from the Tor project) is ok, or even no other jars, not even metrics-lib would work. Is there some general Tor release rule about such things?

There are no general rules about these things, so we can make our own. Should we resolve #13089 (moved) first? Yes, one step at a time.

Cool! Pushed my task-13088 branch and another commit that starts assigning version numbers. Let's revisit this ticket once #13089 (moved) is resolved. Thanks!

Looks like it's time to tackle this issue now with the input from #13166 (moved) :-)

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

This can be closed when the first version 3.1.1 is released.

Trac:
Reviewer: N/A to N/A
Milestone: N/A to Onionoo 3.1.1

Owner wasn't set.

Trac:
Status: new to assigned
Owner: N/A to iwakeh

Milestone renamed

Trac:
Milestone: Onionoo 3.1.1 to Onionoo 3.1-1.0.0

Set to ready for merge as all that's left is making the release.

Trac:
Status: assigned to merge_ready

Closing as the actual release and necessary changes are tracked in #20712 (moved).

Trac:
Status: merge_ready to closed
Resolution: N/A to implemented

closed

mentioned in issue #16371 (moved)

mentioned in issue #16746 (moved)

Versioning and Releases

Child items 0

Activity