Kryo 2.23

[brianfromoregon]

Any timeline to release 2.23? Trunk has a feature I'm looking forward to.
Thanks.

[magro]

I can cut a release this weekend or next week (currently on holidays).

@NathanSweet @romix Is there anything open that should make it into the release?

[NathanSweet]

Not AFAIK.

-Nate

On Tue, Jan 14, 2014 at 9:47 PM, Martin Grotzke [email protected]:

I can cut a release this weekend or next week (currently on holidays).

@NathanSweet https://github.com/NathanSweet @romixhttps://github.com/romixIs there anything open that should make it into the release?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/173#issuecomment-32305678
.

[romix]

As I mentioned before on a different issue, I have a few improvements proposals (with implementations) for making a more compact serialized representation. But they would introduce binary incompatibilities for serialized data. If we think it is better to introduce (if at all) such changes later, i.e. after 2.23, then there is not much to be done for this release from my side.

May be I'll have a closer look at some FieldSerializer related internal classes and reduce their visibility, to avoid any binary API incompatibility problems in the future. I'll try to finish it until Saturday.

[serverperformance]

Hi!

Nate, maybe you could review and merge my pull request #165 that completes the pr #164 and add unit test tests, before freezing the 2.23 version.

After that merge, I will do the pull request to fix the minor PermGen issue #170 as discussed, so you can decide if it goes in 2.23 or delayed to 2.24, of course.

Cheers,

-Tumi

De: romix [mailto:[email protected]]
Enviado el: miércoles, 15 de enero de 2014 8:51
Para: EsotericSoftware/kryo
Asunto: Re: [kryo] Kryo 2.23 (#173)

As I mentioned before on a different issue, I have a few improvements proposals (with implementations) for making a more compact serialized representation. But they would introduce binary incompatibilities for serialized data. If we think it is better to introduce (if at all) such changes later, i.e. after 2.23, then there is not much to be done for this release from my side.

May be I'll have a closer look at some FieldSerializer related internal classes and reduce their visibility, to avoid any binary API incompatibility problems in the future. I'll try to finish it until Saturday.

—
Reply to this email directly or view it on GitHub #173 (comment) . https://github.com/notifications/beacon/6210680__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNTMwNTA3NiwiZGF0YSI6eyJpZCI6MjM0NTU4Njd9fQ==--db12ad832ed2c2f1df89c1d6c77b8b434c11d2d8.gif

[themccubbins]

I'm also needing to get a bugfix that was done since the last release. Any updates on when this might happen?

Thanks!

[romix]

May be I'll have a closer look at some FieldSerializer related internal classes and reduce their visibility, to avoid any
binary API incompatibility problems in the future. I'll try to finish it until Saturday.

This was committed last week.

[romix]

I think a quick fix for #176 should also go into this release, if there are no objections. It will just a few lines long and remove a few unused fields.

[serverperformance]

Maybe you can also do the same removal in DefaultStreamFactory and FastestStreamFactory and so issue #174 could be closed too for the same price? J

De: romix [mailto:[email protected]]
Enviado el: jueves, 23 de enero de 2014 11:00
Para: EsotericSoftware/kryo
CC: Tumi
Asunto: Re: [kryo] Kryo 2.23 (#173)

I think a quick fix for #176 #176 should also go into this release, if there are no objections. It will just a few lines long and remove a few unused fields.

—
Reply to this email directly or view it on GitHub #173 (comment) . https://github.com/notifications/beacon/6210680__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNjAwNDAyMywiZGF0YSI6eyJpZCI6MjM0NTU4Njd9fQ==--c2e38d4e611d9044c999852602e201515063e6d7.gif

[romix]

@serverperformance Yes, fixing DefaultStreamFactory and FastestStreamFactory is a good idea. This won't fix #174 completely, but would help a bit. I'm going to remove the field "kryo" in these two classes, but I'm not going to remove the "setKryo" method, as it should be implemented according to the StreamFactory public API. May be implementations of this method would do something useful in the future.

[romix]

OK. Changes are in trunk now.

[magro]

So shall I cut the release now? I'd release it as 2.23.0 because IIRC we agreed on switching to semver (with a slight interpretation of major/minor version changes: major version shall only be changed when the serialization format was changed). Ok?

Do we want to prepare a Changes doc that lists changes and perhaps also provides compatibility info?

[romix]

On my side - I'm ready.

@magro Just got a report a possible bug: https://code.google.com/p/kryo/issues/detail?id=112 If it is real bug, we probably need to fix it before release, most likely.
BTW, what about your class resolver changes from #182? They are not in trunk yet, or?

@NathanSweet Nate, could you comment on #182? Should we include it or not in its current form? What do you think?

Regarding the Changes doc: Yes, it would be nice to provide it and describe changes, fixed issues, compatibility info, etc.

While looking at the docs, I also noticed that our documentation on the main page is not quite up-to-date. Many topics are not covered: class resolvers, stream factories, instantiator factories, etc. We may want to improve it for a release or short after it.

[serverperformance]

Ok!

De: romix [mailto:[email protected]]
Enviado el: jueves, 23 de enero de 2014 14:11
Para: EsotericSoftware/kryo
CC: Tumi
Asunto: Re: [kryo] Kryo 2.23 (#173)

@serverperformance https://github.com/serverperformance Yes, fixing DefaultStreamFactory and FastestStreamFactory is a good idea. This won't fix #174 #174 completely, but would help a bit. I'm going to remove the field "kryo" in these two classes, but I'm not going to remove the "setKryo" method, as it should be implemented according to the StreamFactory public API. May be implementations of this method would do something useful in the future.

—
Reply to this email directly or view it on GitHub #173 (comment) . https://github.com/notifications/beacon/6210680__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNjAxNTQ0MiwiZGF0YSI6eyJpZCI6MjM0NTU4Njd9fQ==--e25d67bbdbff9c4e707831e7a885dc5cd9c93cca.gif

[magro]

On my side - I'm ready.

Great.

BTW, what about your class resolver changes from #182? They are not in trunk yet, or?

Nope, but this issue could also wait for the next release, it's not that critical to me. So we can take time for the proper solution.

Regarding the Changes doc: Yes, it would be nice to provide it and describe changes, fixed issues, compatibility info, etc.

I try to put s.th. together this evening.

While looking at the docs, I also noticed that our documentation on the main page is not quite up-to-date.

I don't think I'm the right one for this job. I think it's ok to finish documentation after the release. Shall we keep track of missing docs using issues?

[romix]

I think it's ok to finish documentation after the release.

OK.

Shall we keep track of missing docs using issues?

This is a good idea. We can mark such issues accordingly as "documentation"

[magro]

I started to prepare a CHANGES.md based on git log: CHANGES.md. It's basically a cleaned git log with issue titles included.
@NathanSweet @romix You can check the CHANGES_orig.md for comparison.

I'll also add links to issues and add a section that mentions compatibility.

For the future it would be great if we could better automate generation of CHANGES, e.g. by adding "markers" to commits that shall make it into the changelog (see e.g. https://coderwall.com/p/5cv5lg).

For reference the git log command I used:

git log --no-merges --pretty=format:'* %s ([%h](https://github.com/EsotericSoftware/kryo/commit/%H))' 6bc1eabd..HEAD >> CHANGES.md

[magro]

Btw, I didn't pull the latest changes so there are commits missing...

[magro]

I just pushed 2.23.0 to sonatype / maven central.