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

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

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