On Tue, Feb 18, 2020 at 4:59 PM Christopher Currie <[email protected]> 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 <[email protected]> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10gJ945nOuaUER99p_xhMVf1Nbx2hzQcdu1z0o4MKaMDBg%40mail.gmail.com.
