Opened 3 years ago

Closed 3 years ago

#20404 closed enhancement (implemented)

DescriptorIndexCollector should be default implementation

Reported by: iwakeh Owned by: iwakeh
Priority: High Milestone: metrics-lib 1.5.0
Component: Metrics/Library Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

DescriptorIndexCollector should be default implementation as a basis for CollecTor 1.1.0

Child Tickets

Change History (13)

comment:1 Changed 3 years ago by iwakeh

Owner: changed from karsten to iwakeh
Status: newassigned

comment:2 Changed 3 years ago by iwakeh

Priority: MediumHigh
Status: assignedneeds_review

Please review the change.

comment:3 Changed 3 years ago by karsten

Merged, together with a change log entry.

However, this is a major change, because we're now requiring Gson for all applications. Does that mean we should call it 1.5.0 and not 1.4.1?! Hmmmmm.

comment:4 Changed 3 years ago by iwakeh

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.

Last edited 3 years ago by iwakeh (previous) (diff)

comment:5 Changed 3 years ago by 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.

So, in CONTRIB.md we 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!

comment:6 in reply to:  5 Changed 3 years ago by iwakeh

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.md we 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.)

Last edited 3 years ago by iwakeh (previous) (diff)

comment:7 Changed 3 years ago by karsten

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

comment:8 Changed 3 years ago by iwakeh

This tar looks fine. All tests pass, also Collector tests using this pre-release (see #18910).
The jar was build from the provided sources.

Ready for release.

comment:9 Changed 3 years ago by karsten

Released! Please let me know what changes to Trac milestones I should make.

comment:10 Changed 3 years ago by iwakeh

Milestone: metrics-lib 1.4.1metrics-lib 1.5.0

comment:11 Changed 3 years ago by iwakeh

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.

comment:12 Changed 3 years ago by karsten

I think I made all milestone changes. Please close this ticket if nothing else needs to be done here. Thanks!

comment:13 Changed 3 years ago by iwakeh

Resolution: implemented
Status: needs_reviewclosed

This is releases already.
Closing.

Thanks!

Note: See TracTickets for help on using tickets.