Draft-js: Next release 4.0.0 instead of 0.4.0

[nikgraf]

Following the trend of React & Jest it would be great to move to a version schema where breaking changes lead to a bump in the major version number.

What are you thoughts on this?

[max-mykhailenko]

@nikgraf I think product doesn't ready for production

[nikgraf]

@max-mykhailenko It's in production since quite a while (weeks? months?) at facebook.com. I would argue that this qualifies it to be production ready. How do you feel about it?

[max-mykhailenko]

@nikgraf support of tables and media is not so clearly, documentation and examples are poor. Library can work, but without good documentation and examples it's not production ready solution.

[hellendag]

This framework has been in use in production on facebook.com for over a year and half.

It currently powers the main status input, comments, messenger.com, Notes, and a number of other critical interfaces across products. All releases strictly include changes that are already live on facebook.com.

It may not currently have features that would allow your specific use case to be production-ready, but that's up to you. :)

@nikgraf: I don't really have a strong opinion on this. I think releases will probably be rolling every week or two, and I feel like it might get a little out of hand to increment the top-level number every time. @spicyj, opinions?

[remko]

I think what @max-mykhailenko is probably referring to is not code stability, but API stability. With releases rolling every week with API changes (some of them breaking, such as atomic), still several pending changes (metadata on block), and talks of more changes (integrating entities as immutables into the model), it feels from the outside that the project is in a lot of flux, and not in the state yet where you can drop it in as a dependency in a production project and forget about it (or, from the Draft maintainers point of view, to start worrying about which version component to bump on every release). But this might just be external perception (we only see a 2 month project that has had several API changes).

I don't think it matters much technically whether you bump the 0. minor or the major, it's just perception and maintenance overhead I would think.

[zpao]

I think releases will probably be rolling every week or two, and I feel like it might get a little out of hand to increment the top-level number every time.

I think this is the part that gets me and made me argue for starting at < 1.0.0. At this point the project and API have been changing a lot as we take in external ideas and needs and is evolving rapidly. While the core itself is quite stable, the API is changing. I think it makes sense to get this all out now and get to a point where we aren't changing top level API every 2 weeks, then call that 1.0.0 and go from there.

[nikgraf]

sounds good :smile: