How alpha is pre-alpha?

[jdormit]

Hi! I'm evaluating different schema validation/conformance libraries. My use case is to validate the shape of data coming into an API from client applications, returning useful error messages to the clients. Out of Schema, Spec, and Malli, I like the philosophy and API of Malli the best. But I'm a bit worried about Malli's "pre-alpha" status. Would I be making a mistake choosing to build a production system on Malli in its current form?

[rschmukler]

I'm sure metosin will have better feedback, but I've been using malli for about 6 months across two different projects, including one in production and can share my experiences.

During that time it has undergone one major overhaul for transformer internals and was spurred by functionality that I needed for an application (see #114) which required a bit of refactor. Beyond that most of the changes have been minimal - but they do occur (eg. see the recent #206 PR merge). This is important to consider if you plan on building infrastructure on top of malli (eg. transformers, visitors, etc.)

Also, there are tiny bugs that crop up from time to time (eg. #200 ). Most of these exist within the fringe and aren't too major - but depending on your projects' needs it's something to be aware of.

That being said, there are a few advantages in the youth of malli:

1. The velocity is impressive. Generally things are fixed quite quickly after being reported.

2. The repository is relatively simple to understand and well designed; and the team has been extremely receptive to contributions and bug fixes.

3. It can become better. As you mentioned - if you buy into the philosophy, the repository is actively improving - eg. the recent :string schema enhancement (welcome :string schema #205). Again, kudos to @ikitommi and the other maintainers for being so receptive to feedback.

Hopefully some of this helps you make your decision. It's definitely been awesome watching the library continue to take shape over the last six months and I personally do feel comfortable using it production - but I own the project fully and am willing to do a bit of extra maintenance as malli evolves.

[jdormit]

Thanks for the insight @rschmukler! I'm not currently planning to build up any complicated infrastructure around Malli - just basic incoming data validation. Given what you've said, I think I am going to go with Malli for now but keep it contained to a small part of my codebase. Excited to see where the project goes!

@ikitommi / whoever, feel free to close out this issue if there's no more useful conversation to be had. I'm going to keep it open for now in case anyone else has anything to add.

[ikitommi]

Thanks Ryan, both for the kind words and your contributions. Goal is to go post pre-alpha this month as most of the design choices have been discovered and decided already. Last bigger things are #86, #20 and ensuring the small bundle size (#203). There are so many things on the roadmap, but there is always time after pre-alpha to do those.

(Breaking) changes before the release are tracked on the CHANGELOG.

[miikka]

Is the first release really going to be alpha? As said, Malli has seen already quite a bit of production use and since the goal has been to do all the necessary breaking changes before the first release, I assume we're going to have some backwards-compatibility goals afterwards.

Consider clojure.spec. The first version was called alpha and the next version alpha2, but in practice, the first version was 1.0 and the second version is 2.0. What would even be the point of a non-alpha, "production ready" release of clojure.spec at this point?

[ikitommi]

My suggestion:

• we could set a goal to ship out 1.0.0, after getting all the features in, after proper feedback from the users from the alpha, with proper docs etc. ~"end of this year"?
• we should ship a first non-pre-alpha now (just few small improvements & cleanng up the corners), it could be 0.1.0
• rules for alpha, something like BREAKVER-1
  • we try to keep the public api without any breakages (and deprecate things if needed), collect potential big breaking changes for 1.0.0. We can break small things and it will be a MINOR => track the CHANGELOG.
  • using the extension apis (e.g. public vars with - in the name like m/-explain), things can break more (but we try not to) => track the CHANGELOG.
  • with 1.0.0, all deprecations are thrown away and we will party

[miikka]

• rules for alpha, something like BREAKVER-1

How does your suggestion differ from BREAKVER?

[ikitommi]

looking at my previous comment and the Malli CHANGELOG description, not much. But wanted to give warning that the advanced/extender api can break more, e.g. major changes as it's still alpha.

[ikitommi]

accidentally hit close. Let's keep this open for a while

[miikka]

So you mean that you don't want to bump it to 1.0.0 on major changes?

[ikitommi]

there is a alpha-guide in #272, which will fix this.