I'm a long time Jackson user and almost always use it alongside Kotlin these days. I'm happy to lend a hand in management of the module going forward; I have significant Kotlin expertise, having used it since right when 1.0 was released, though the internals of the Jackson Kotlin module are new to me.
-Drew On Tuesday, February 18, 2020 at 11:19:01 PM UTC-5, Tatu Saloranta wrote: > > On Tue, Feb 18, 2020 at 4:59 PM Christopher Currie > <chris...@currie.com <javascript:>> wrote: > > > > Coming out of hibernation to drop some thoughts: > > > > While I sympathize with the idea of not making new releases until a > maintainer is found, the unfortunate side-effect of that will be to > lock-out Kotlin users from any critical fixes that might occur in Jackson > proper, unless it can be guaranteed that last 2.10 release will be forward > compatible, which sounds unlikely if you're targeting a major version as > the next Jackson release. > > Right, good points. Moratorium (if any) would not be meant as > punitive, esp. so not for users. > > So at very minimum testing to keep 2.10 of module compatible should be > done. > > I also think that I will probably not do this for 2.11, yet, at least. > That one blocker issue is something I can probably work around by > adding feature (to select singleton handling). > This would give more time and not force the issue too early. > > I need to gather some more thoughts as I think there are basically 3 > issues (of which just 1 wrt Kotlin) to resolve before 2.11. And maybe > minor 4th question on whether there is need for a RC/alpha/beta > version. > > > That said, holding a release of the next version until a maintainer can > be found does make some sense, if it's going to happen eventually, as it > gives that maintainer an opportunity to make the next release solid, rather > than having to wait for the next patch release train for fixes or > improvements. So I guess I'm coming down on the side if "sounds reasonable, > for a short time." Better to not release right away, and keep your options > open, and re-evaluate if there's a lot of demand for a release. > > > > On the maintainer side, perhaps a team of approvers? Github now supports > configuring a repo to require a certain number of reviews before merging; > if you've had multiple offers for maintenance, a team of at least three, > configured to require two positive reviews, may help to guard against risky > merges. > > Yes, I think that there are good mechanisms for helping with practical > aspects. > What I would like to resolve is just the conceptual part: agreements > -- who should and has the right to decide, in a way that tries to > balance stability of changes (reviewing) with efficiency of getting > changes merged (merging what is considered a good change). > > > > > HTH, > > Christopher > > Thank you, this is helpful. > > -+ Tatu +- > > > > > > > > > On Tue, Feb 18, 2020 at 1:14 PM Tatu Saloranta <ta...@fasterxml.com > <javascript:>> wrote: > >> > >> So. I think that the current semi-existence of Jackson Kotlin module > >> is not good for anyone. While there has been positive progress wrt > >> many features in 2.10, there have been a few new issues that are > >> partly my fault for not being able to properly sanity check risks, > >> concerns, or weight effects of changes. > >> A particular example would be changes in 2.10 to handling of Singleton > >> values, where situation is pretty close to lose-lose: regardless of > >> whether to just blindly skip matching JSON content (2.10 behavior), > >> return Singleton, or deserialize content, drop resulting instance and > >> return Singleton (2.9 and before). > >> > >> At this point my feeling is this: unless a new set of active > >> maintainers can be found, agreed upon, I do not think I should release > >> new minor versions of Kotlin module. That just gives false impression > >> of maintained component. > >> > >> On plus side, multiple individuals have mentioned they would be > >> interested in helping -- big thank you to everyone. > >> But the problem here is this: since I can not properly judge > >> development of the module, I also can not quite figure out how and who > >> to hand over guardianship either. > >> > >> I would be very interested in hearing suggestions, proposals for > >> finding new owners: and one of few things I have opinion about this > >> here is that ownership should be shared across more than 1 individual > >> (but probably no more than 2 - 4). > >> > >> So. WDYT? > >> > >> -+ Tatu +- > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "jackson-dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to jacks...@googlegroups.com <javascript:>. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-dev/CAL4a10jSFPzGqZJGSyDvrfpWyGRpeFiH2%2BWBphSZev_EXZuGMQ%40mail.gmail.com. > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "jackson-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to jacks...@googlegroups.com <javascript:>. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-dev/CAFkNez9G6pV0wpRcXG9D7tT1JquEZWyqyt8nn%3D0ZWWi6pMROYQ%40mail.gmail.com. > > > -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/9e9f0fbf-d0b6-4640-8ec2-ff602eaa81ba%40googlegroups.com.