Future roadmap and maintentance challenges

[MateuszKubuszok]

At the moment we are mostly waiting for the feedback and bug reporting to see if the total rewrite required by 0.8.0 haven't broken anything. Additionally, we have a few points we would like to address before releasing 0.8.0 (the biggest being how we want to change how automatic derivation works).

It will take a while, especially since I need a break after the marathon for that release.

But at some point we will have to discuss what's next and which of the existing tickers we actually want to ever implement?

• after the recent rewrite we have a bus factor of 1, after a while we will return to 2 - but that's something we need to address
• each new feature only adds to the maintenance burden - so which new feature would actually contribute anything?
• so far each feature development required both main maintainers to basically take a time off and do a 1-2 week long hackaton, this is impossible to sustain and results in e.g. 1.5 year long breaks in development
• I'd like to have a 1.0 version at some point, but that would require stabilizing API and behavior for good, and there are some features which would force us to break the API - so we'd have to make decisions which of them we want to eventually implement and which would be wontfix

To make it easier to us to asses how much effort would be needed to implement things with out current codebase (we can simplify this and that, but I do not expect wonders), I created a few drafts:

Chimney implementation ideas

These address issues/tickets which I believe would be the most impactful on the codebase (not necessarily on the users). IMHO each of these is doable, but it looks like a several months of full time work, after which codebase would gain another 10kloc (including tests).

Any thoughts?

[MateuszKubuszok]

After reading our own tickets and Ducktape's ones I think we can consider these featured to be added to make Chimeny "feature complete" (not as in finished, but as "comparably done to e.g. MapStruct or AutoMapper"):

• mapping multiple sources into a single target value ("merge transformers") (Support for mapping multiple case classes #115, Question: Transformer from > 1 case classes to another #208)
  • when combined with policy checking (Policy for checking which fields were used for transformation #248) Patchers could be reimplemented as merge transformers (Patch, Source) => Source, by making merging recursive we would provide recursive Patchers (Nested patchers don't work with subset of fields #119, Support nested patchers that look for implicits #133) and better customization (Support custom patching logic #134, Allow to ignore specific field in patchers #161). It would be useful to proceed it by Implicitly scoped patcher configurations #191
• implementing custom constructor (Transform through method other than default constructor #192) for target type would let us catch up to Ducktape with feature parity (it is something Ducktape as and we don't)
• adding nested paths in all .withField* (and maybe in future something for selecting a subtype) similarly to what is planned for Ducktape 0.2.x ([0.2.0] allow configuration of nested products/coproducts arainko/ducktape#74)

ATM we are releasing unstable releases on 0.8.0 with tags like "milestone 1", because we are still missing a few things to make it stable. We trace them in the milestone for 0.8.0. We can use that opportunity to introduce all breaking changes we can predict at once, so that people migrating from 0.7.x would experience them exactly once.

So, what breaking changes we would still have to introduce?

• we need to rethink autoderivation (already in 0.8.0 milestone) Ability to not use auto-derivation #166
• we need to change format of storing field names in the type level to allow longer paths in the future, to enable [0.2.0] allow configuration of nested products/coproducts arainko/ducktape#74 counterpart
• we would have to add implicit PatcherConfiguration since it adds another type parameter and an implicit value in .using(p).patch Implicitly scoped patcher configurations #191

These could be done before releasing 0.8.0, which would allow adding all of these new features in purely additive way.

What breaking changes would be left if we wanted to finally release 1.0?

The ones which requires users' feedback: which defaults are sane and convenient, which methods/types could be better named, etc. This would be best done after all of these features would be implemented, so that people could use them and have some thought about them.

As a result we could have a roadmap like this:

• 0.8.0-M2, 0.8.0-M3, ... - fixing unstable branch, without any stability guarantees
• 0.8.0 - all breaking changes mentioned above, users have some migration to do, but they perform it only once, and they are done for a while
• 0.8.1, 0.8.2, ... - adding new features in backward compatible way
• 1.0-M1, 1.0-M2, ... - changing defaults and naming based on feedback, unstable series of pre-releases
• 1.0.0 - finally a stable version

IMHO it sounds doable and strikes a nice balance between sticking to API people complain about and breaking things every 3 months for everyone. But we would have to make decisions which features we would like to eventually implement and which are off the table.

[MateuszKubuszok]

For now we're going to stabilize 0.8.0:

• Enable MiMa on CI tests for JVM versions #385 will check that no backward incompatible changes are made
• Ability to not use auto-derivation #166 was merged, we'll see if there is any feedback about it - if there are issues we can address them in future 1.0-RC series
• Implicitly scoped patcher configurations #191 was merged, so any future work on Patchers should be purely additive changes to API
• Introduce Path type intended for storing nested path in type level #377 was merged, so any future work on nested paths should only change behavior of macros without breaking the existing code

[MateuszKubuszok]

It seems that 0.8.x fulfilled its role.

There might be a release or two in 0.8.x line, but I already started working on improvements that would have to happen in 1.0.0-RC, as they are breaking changes. It seems that so far we do not have any features planned that would require us breaking anything, so we might implement them after 1.0.0 will be released, as 1.1.0, 1.2.0, etc.

The roadmap kinda worked as planned - even though I haven't gotten any external feedback :P - and I can close this discussion.