-
Notifications
You must be signed in to change notification settings - Fork 125
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
Release 1.0 #185
Comments
Is it the moment to remove deprecations? |
👍 Agree, exactly that! |
While I agree that both #184 and #153 would be nice to have improved - I'd opt for releasing 1.0 without blocking on them. We have a nice, working system, the API is not perfect (and never will be for everybody) but we support many use cases (aggregates, linking to many streams, using read models, process managers). There are no known bugs. It's all what I'd expect from having RES 1.0. My suggestion - let's release 1.0 with what we have now and include #184 and #153 as main improvements for 2.0. Maybe we could celebrate releasing 1.0 during wroc_love.rb? :) |
I would also suggest #126 as part of 1.0 release |
Closing as we've scoped that already https://github.com/RailsEventStore/rails_event_store/milestone/3 and I doubt there's much more to discuss on this topic. |
@pawelpacana ok, great. Reviewing what was proposed there, I'm going to go with the "upsert" version in #476. Might need some help with mutations, but getting things sync'd up with master right now. Thanks. |
There has to be finally a release after which one could expect stability in terms of public API.
Not long ago we've changed database schema heavily (0.19.0) to fix potential concurrency-related issues. That was a major blocker, at least from my perspective. So are we ready now? What else seems crucial before we freeze public API and behavior?
I'd suggest reviewing #184 and #153 as both touch public API.
The text was updated successfully, but these errors were encountered: