makes for a tidier PR
whats the plan for v4 in general?
@oskardudycz @mysticmind @jokokko About v4, I know the original plan was to concentrate on the event store, then worry about Linq in v5. Then it was do everything breaking in v4 and let the dust settle
I’m making some decent headway toward the Linq provider in a local branch. How would you feel about a relatively quick v4 with very minimal breaking changes but a lot of Linq improvements and some of the performance improvements, then bear down on v5 for a longer, bigger overhaul of the event store?
I'd like to avoid breaking changes as much as possible
So only very advanced users would be impacted
I’m more scared of having long-lived branches
So I'm not against that
What I'd like to also avoid
is the casus of the Angular
Oh lord, yeah
then people stopped using Angular 1 and switched to react because they knew that they'll need to do the revolution
(besides the fact that Angular 1 was shitty)
So to sum up, I'm fine with that as long as we won't keep the users waiting for too long for v5
now I feel that we're starting to catch some momentum so it would be good to keep it
So for a v4 maybe:
- All the Linq improvements. I think we’ll be able to do the Include() against collections, better collection sub-query, better
SelectMany(), and just faster all the way around because the SQL is a touch more performant and the Linq parsing definitely is. I also think theInclude()mechanics would be faster - There’s some opportunity to improve the JSON serialization usage by centralizing the memory pooling. The improvements we did for v2 aren’t applied everywhere, and I think it’s going to be better to encapsulate that into
JsonNetSerializer. That’s a potentially big performance / memory usage win - Do the Json streaming story finally because I think that’s a good demo
- Maybe do the new dynamic code generation w/ generated code. If we could do that, I think there’s a lot of performance fat we could eliminate in the identity maps, the unit of work mechanics, the SQL generation, and the selector code
- If we did the previous bullet point, go after the document metadata as well
And 6.) whatever Linq bugs or issues are open. I started playing around with Common Table Expressions in Postgresql, and it opens up a lot of possibilities for us I think.
And possibly 7.) Split out the db helpers
Another possible advantage to think about, if v4 is coming faster, maybe we can kick out 3.12 faster as well by knowing we’ve got a shot at getting other bug fixes in shortly for a new release that won’t be too hard to switch over to
but we can change the plan
Another alternative would be to kick out alpha releases, but I hate fiddling with that from the release side of things
so probably it's better to just go with v4
I think that we can squeeze as much as we can till eg. next Sunday
then focus on Linq
Probably most of you have seen that, but that's really creepy story https://medium.com/@keivan/the-day-appget-died-e9a5c96c8b22
As an end user, the most valuable thing is a steady stream of changes, not an Apple-style release cycle.
Breaking changes (with proper semver) is fine if the changelog has good upgrade steps. If the docs are good theres not much to complain about breaking syntax changes.
Lots of paradigm changes might be an issue but that seems unlikely
Breaking changes (with proper semver) is fine if the changelog has good upgrade steps. If the docs are good theres not much to complain about breaking syntax changes.
Lots of paradigm changes might be an issue but that seems unlikely
2 replies
