Package status

[SI-IC]

Hello there!
I was wondering if I could use your package for production, or if it is still in active development?

Thanx.

[Oudwins]

Hey!

Glad you like the package! This has been quite a common question, so let me try to explain best I can in hopes that it is also useful for others.

I don't think there is a way I can tell you specifically if zog is ready for you to use in production. As different people have different metrics for this. What I can do is give you as much information as I can about values, goals and roadmap in hopes that that helps you answer the question for yourself.

First, my philosophy for Zog development is quite conservative. Meaning I really do not want to have breaking changes and prefer waiting until we have the correct API before releasing. This often leads to slower iteration times but it hopefully makes it so we have less breaking changes. However, I'm not infallible, sometimes I make a mistake and we have to change something. Since we are pre v1, if we have high certainty that the change is correct we will do it. I'm also quite a bit more happy to change things that do not affect the core Zog user facing API (i.e what 99% of users use). This will probably grow even more conservative once we hit v1.

But what does this actually mean in practice? What are the things that might change and how might they change? What are the things that will almost surely never change? Again this is purely informed speculation I cannot grantee anything, but here are my thoughts:

things that will never change

• Core API schemas i.e z.String(), etc. This API has been the same since the beginning. It works, its familiar, even if the entire internals of Zog were to change this would most likely stay the same. Mostly what will happen is that they will get more methods.
• Basically this means that schemas from Zog v0 and v10 should look virtually identical
• Errors. They are just in a really good state. They do everything I want them to.

Things that will probably change.

• I would like to improve the typesafety for struct schemas, which will in turn allow us to use generics to improve the typesafety for all the remaining schemas (all non primitive schemas). There are several approaches we can take for this most of them will probably require some kind of minor breaking change around defining z.Struct schemas. For example you might have to provide a generic to the shape z.Struct(z.Shape[myStruct]{...})
• Some internals around parsing might also change. Since its not very efficient at the moment. But this shouldn't affect the user facing API.

Roadmap/Other things that are planned

• My main focus right now is codegen. But this will be used to enhance current workflows and allow Zog to do new things that I don't foresee requiring breaking changes
• New API for creating custom reusable schemas. Which should only be relevant to other people wanting to make libraries that interface with Zog.
• New schemas (i.e maps, etc).
• New validation methods
• Additional performance optimizations (which again won't affect current API since Zog will always choose DX over perf)

I know this was a lot, but I hope it was somewhat helpful. The TLDR is that: Zog has a really strong foundation. I don't expect anything major to change. But if you want a package that you are sure will have long term support for the current version without even minor breaking changes, maybe wait. Otherwise, sure. I am personally using it in a few production projects and there are thousands of other devs doing the same.

[SI-IC]

Thanks a lot for the detailed reply.