Release of version 3.2

[poojke]

Hi,

First up, thanks for releasing the code!

If possible, could you provide an ETA for the release of version 3.2? The recent Serialisation changes (#56) together with the pending PR #66 would allow us to use your library as is.

Thanks

[tdunning]

I can't say a date but I am stealing time here and there to make progress. I would like to introduce the new array form, but may delay that to 3.3 to avoid being too slow. The serialization changes are a big improvement to usability and need to go in.

Sent from my iPhone

On Jun 15, 2016, at 17:03, poojke [email protected] wrote:

Hi,

First up, thanks for releasing the code!

If possible, could you provide an ETA for the release of version 3.2? The recent Serialisation changes (#56) together with the pending PR #66 would allow us to use your library as is.

Thanks

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[instanceofme]

Same here, we could use the Serializable :)

[tibidoh]

H! A kind reminder about releasing the serialization updates.
Meanwhile, would it be possible to have at least a snapshot released with those changes?

[tdunning]

Yes. Thanks for the kind reminder.

A release is absolutely doable.

On Mon, Nov 21, 2016 at 7:14 AM, Alexander Oleinikov <
[email protected]> wrote:

H! A kind reminder about releasing the serialization updates.
Meanwhile, would it be possible to have at least a snapshot released with
those changes?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#67 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPSemhCvVwjTBRUmmsonzwU1cOiR_ymks5rAbVngaJpZM4I26Of
.

[chonton-elementum]

Any ETA? Do you need help?

[tdunning]

That would be grand. There are just a few main issues before us. Not all are strictly necessary: 1) the tests have grown like topsy over time and it isn't clear that all of them make sense anymore. That may be why some are failing. Or it could be good tests finding bad implementation. Either way, this needs to be resolved before a next release. 2) the accuracy runs need to be repeated with the two main remaining implementations (AVLTree and MergingDigest). This information needs to be summarized in a boring way. And the t-digest-benchmarks need to be updated and run for the two algorithms in a consistent way. 3) the paper needs updates from (2) and a bit more clarity in the relationship of the two implementations. 4) the API needs to be cleaned a bit. Old implementations should be pruned and the default should be addressed. The new merge function from MergingDigest needs to be promoted to the top-level. 5) The question of serialization should be put to bed and all (two) current implementations need to be verified to serialize and deserialize correctly. I would like it if the two implementations could inter-operate as well so that a MergingDigest could be deserialized from an AVLTree digest. There should be a default TDigest deserialization as well. I think that (3) is squishy and not blocking. Even (4) might be non-blocking. Items (1) and (5) are definitely blocking and I lean toward blocking on (2). Your thoughts?

…

On Fri, Feb 3, 2017 at 2:45 PM, Chas Honton ***@***.***> wrote: Anyone ETA? Do you need help? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPSerHVDXJrWgt6qxUXAj5422zCXVevks5rY63ygaJpZM4I26Of> .

[tdunning]

A release is (really!) coming soon.

Serialization really works now. And there is a roadmap for improvement beyond what we have now.

The API has been cleaned up, the paper is half fixed (I will defer that in favor of getting the release out) and the tests are all clean again.

[iemejia]

Big +1 for the new release. Are the blockers still active, anyway we can help getting this out?

[tdunning]

Ismaël, There is one serious potential blocker that I may just take as a known defect. See #89

…

On Tue, Jul 18, 2017 at 4:46 AM, Ismaël Mejía ***@***.***> wrote: Big +1 for the new release. Are the blockers still active, anyway we can help getting this out? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPSem9HqnANfSk6wRUKT89v6ftE3q1pks5sPJsFgaJpZM4I26Of> .

[tdunning]

We also have some pending work on serialization. I may accept that as not done as well and push it to a dot release.

…

On Thu, Jul 20, 2017 at 8:57 AM, Ted Dunning ***@***.***> wrote: Ismaël, There is one serious potential blocker that I may just take as a known defect. See #89 On Tue, Jul 18, 2017 at 4:46 AM, Ismaël Mejía ***@***.***> wrote: > Big +1 for the new release. Are the blockers still active, anyway we can > help getting this out? > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#67 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAPSem9HqnANfSk6wRUKT89v6ftE3q1pks5sPJsFgaJpZM4I26Of> > . >

[iemejia]

Just wanted to thank you for the release and for this lib in general @tdunning . For info the library is no integrated as an extension in Apache Beam too :)
apache/beam#4611