[tor-bugs] #13088 [Onionoo]: Versioning and Releases

[Tor Bug Tracker & Wiki]

#13088: Versioning and Releases
-----------------------------+-----------------
     Reporter:  iwakeh       |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------

Comment (by karsten):

 Replying to [comment:2 iwakeh]:
 > Replying to [comment:1 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
 [https://gitweb.torproject.org/user/karsten/onionoo.git/shortlog/refs/heads/task-13088
 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13088#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online