DescriptorIndexCollector should be default implementation
DescriptorIndexCollector should be default implementation as a basis for CollecTor 1.1.0
Activity
changed milestone to %metrics-lib 1.5.0
Please review the change.
Trac:
Priority: Medium to High
Status: assigned to needs_review-
Oh, I wasn't aware of metrics-lib not including the dependencies in the release jar.
As with the other releases a metrics-lib release jar should contain all of its dependencies. We should provide gson with the release jar of metrics-lib, and thus, hide the internal choice of implementation. (Onionoo could then even get rid of that dependency as metrics-lib comes with gson.) But, I think the better solution will be the metrics-tools lib that wraps any JSON-protocol implementation.
Can that be changed with this release, i.e. include dependencies? Then it could even go up 1.5.0 I think.
I think we're leaving third-party jars out of the release jar on purpose. The idea is to avoid version conflicts where we'd be shipping an older or newer version of a library that people use in their applications. I vaguely remember that our version might take precedence over theirs, and that can be bad.
So, in
CONTRIB.mdwe write: "Whenever we add a new dependency, that's clearly a major change that needs to be written into the change log, because applications will have to add this dependency, too." We also write: "For minor changes, we'd bump to x.x.1."The question now is whether we can justify putting out a point release with a major change. I lean towards no. And even a medium change might require a bump to 1.5.0, though I'm less certain about that being a great idea. The question is: should we just call this one 1.5.0 and bulk-change tickets to move them to 1.6.0? Happy to create a milestone for that. Let me know!
-
Replying to karsten:
I think we're leaving third-party jars out of the release jar on purpose. The idea is to avoid version conflicts where we'd be shipping an older or newer version of a library that people use in their applications. I vaguely remember that our version might take precedence over theirs, and that can be bad.
I vaguely remember the discussion back then.
So, in
CONTRIB.mdwe write: "Whenever we add a new dependency, that's clearly a major change that needs to be written into the change log, because applications will have to add this dependency, too." We also write: "For minor changes, we'd bump to x.x.1."The question now is whether we can justify putting out a point release with a major change. I lean towards no. And even a medium change might require a bump to 1.5.0, though I'm less certain about that being a great idea. The question is: should we just call this one 1.5.0 and bulk-change tickets to move them to 1.6.0? Happy to create a milestone for that. Let me know!
Yes, 1.5.0 is right in the view of our earlier definition. (It might even turn into 2.0.0 instead of 1.6.0, but I need to go back and look at the planned items for that release.)
-
Please take a look at this pre-release tarball and let me know if it's good to go, in which case it'll simply become the release tarball: https://people.torproject.org/~karsten/volatile/descriptor-1.5.0-pre.tar.gz
-
This tar looks fine. All tests pass, also Collector tests using this pre-release (see #18910 (moved)). The jar was build from the provided sources.
Ready for release.
-
Fine :-)
1.4.1 can be deleted. 1.5.0 can be closed (or whatever name the milestone-is-done status has). (unrelated: milestone CollecTor 1.0.2 should also be closed and have the release date set.)
I moved the tickets from 1.5.0 to 2.0.0 for the moment. It might be good to add 1.6.0 milestone. So the re-planning has some milestone to move tickets to. Could be though that 2.0.0 ought to be next anyway depending on the tickets.