Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How alpha is pre-alpha? #207

Closed
jdormit opened this issue Jun 11, 2020 · 10 comments
Closed

How alpha is pre-alpha? #207

jdormit opened this issue Jun 11, 2020 · 10 comments
Labels
question Further information is requested

Comments

@jdormit
Copy link

jdormit commented Jun 11, 2020

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
Copy link
Contributor

rschmukler commented Jun 11, 2020

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
Copy link
Author

jdormit commented Jun 11, 2020

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
Copy link
Member

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
Copy link
Contributor

miikka commented Jun 12, 2020

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 ikitommi added the question Further information is requested label Jun 12, 2020
@ikitommi
Copy link
Member

ikitommi commented Sep 18, 2020

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
Copy link
Contributor

miikka commented Sep 19, 2020

  • rules for alpha, something like BREAKVER-1

How does your suggestion differ from BREAKVER?

@ikitommi
Copy link
Member

ikitommi commented Sep 19, 2020

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 ikitommi reopened this Sep 19, 2020
@ikitommi
Copy link
Member

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

@miikka
Copy link
Contributor

miikka commented Sep 21, 2020

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

@ikitommi
Copy link
Member

ikitommi commented Oct 7, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants