New owner(s) for Kotlin Module

[cowtowncoder]

As per my email to jackson-user, I feel there is need for a new set of maintainers for this module, to help author (@apatrida ). I am happy to help with work integrating with databind, and doing releases as necessary, but there needs to be Kotlin domain experts too.

So far following community members have expressed interest:

• Drew Stephens (@dinomite)
• Vyacheslav Artemyev (@viartemev)

Specific near-term challenges for maintainers include:

• KotlinObjectSingletonDeserializer fails to deserialize previously serialized JSON as it doesn't delegate deserializeWithType #281: Singleton instance deserialization changes in 2.10 (current thought: offer on/off feature or enum for selecting from pre-2.10 and 2.10 methods, default to 2.10 handling).

[cowtowncoder]

Quick update: invited @dinomite and @viartemev into Kotlin team, which should give them full commit access once accepted. Will close once this happens, send announcement on mailing list(s).

[cowtowncoder]

@dinomite Now has committer rights. Will need to figure out where to add information (aside from Kotlin README)

[cowtowncoder]

@viartemev Now has committer rights too!

[cowtowncoder]

@dinomite @viartemev Congratulations! I will now go ahead and add a note on README, as well as send a notice on jackson-dev list.

One quick note: I think 2.12 needs to be merged to master: I would merge it but was unsure about Extensions.kt (related to a recent change merged).

[cowtowncoder]

Updated README: feel free to improve upon language or make changes as you see fit (f.ex regarding contact information).

Also: I will think of whether it'd make sense to have a more central place under jackson repo to list maintainers of all modules, and if so, in what form.

[dinomite]

Oh yes, still getting a hang of the branching structure here—I created 2.12 and I'll get it merged to master.

[viartemev]

@dinomite do you mind to describe the releasing algorithm in docs?
The module has a tricky branching model.
A good example can be found here
Also, it's good to have a contributing guide.
This should simplify the work on the project for new contributors.

[dinomite]

I don't know about releasing (@cowtowncoder did 2.11.0), but I'll make a PR for the readme about how I understand the branching model so you all can verify it's correct.

[cowtowncoder]

On release: I use Maven release plug-in, so once version is, say, 2.12.0-SNAPSHOT, I use

mvn release:clean; mvn release:prepare; mvn release:perform

and I'm happy to keep doing this for full release unless someone else really wants to do it.
The reason it works for me is just because there is some coordination on getting full set of versions out; otherwise I would not mind sharing responsibility.
There are some subtleties on jackson-bom / jackson-base: I can go into details if you want.

As to branching: as you know, master is for (still far out.... :-( ) 3.0.0, so most changes at this point go in one of 2.x branches. Simplest way is to start with branch in which inclusion is planned -- for small and safe changes, usually maintenance branch.
Currently I am thinking there will not be any more releases for 2.9 or earlier; and 2.10.4 may well be the last full minor set for 2.10. So at this point, likeliest place to merge changes is 2.11 or 2.12 branch.
It is of course possible to also use cherry-pick if you start from "wrong" branch so starting point is not necessarily a big deal.

But if I commit a change in 2.10, I will try merge 2.10 -> 2.11, 2.11 -> 2.12, 2.12 -> master.
This usually goes cleanly, except for release-notes/VERSION-2.x (and CREDITS-2.x).
Except that 2.12 -> master has some bigger changes due to major API breakage.
My apologies on that: I did not initially realize how long this discrepancy would live.
But I can help with questions on API changes, where change is not obvious.

Documenting these would be great, and I think it is good to have these questions now.
Please let me know parts that seem unclear, as well as any improvement ideas you have.

[cowtowncoder]

Adding Contributing.MD would also make sense; sent a note on jackson-dev (probably makes sense to add to jackson, link from here)