Opened 4 years ago

Closed 2 years ago

#13088 closed enhancement (implemented)

Versioning and Releases

Reported by: iwakeh Owned by: iwakeh
Priority: Medium Milestone: Onionoo 3.1-1.0.0
Component: Metrics/Onionoo Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

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

What about releases?

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

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

Child Tickets

Change History (11)

comment:1 in reply to:  description ; Changed 4 years ago by karsten

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.

comment:2 in reply to:  1 ; Changed 4 years ago by 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.

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).
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?

comment:3 in reply to:  2 Changed 4 years ago by karsten

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 for this.

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

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

comment:4 Changed 4 years ago by iwakeh

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

Yes, one step at a time.

comment:5 Changed 4 years ago by karsten

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

comment:6 Changed 3 years ago by iwakeh

Severity: Normal

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

comment:7 Changed 3 years ago by iwakeh

Milestone: Onionoo 3.1.1

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

comment:8 Changed 3 years ago by iwakeh

Owner: set to iwakeh
Status: newassigned

Owner wasn't set.

comment:9 Changed 3 years ago by karsten

Milestone: Onionoo 3.1.1Onionoo 3.1-1.0.0

Milestone renamed

comment:10 Changed 2 years ago by iwakeh

Status: assignedmerge_ready

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

comment:11 Changed 2 years ago by iwakeh

Resolution: implemented
Status: merge_readyclosed

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

Note: See TracTickets for help on using tickets.