by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 07:41
    trullock edited #1492
  • 07:41
    trullock edited #1492
  • May 28 13:10
    trullock edited #1492
  • May 28 13:10
    trullock edited #1492
  • May 28 13:02
    trullock edited #1492
  • May 28 13:02
    trullock edited #1492
  • May 28 12:59
    trullock opened #1492
  • May 28 12:59
    trullock opened #1492
  • May 28 06:06
    brain-5 opened #1491
  • May 28 06:06
    brain-5 opened #1491
  • May 27 02:09
    jeremydmiller commented #1490
  • May 27 02:09
    jeremydmiller commented #1490
  • May 26 18:42
    tonykaralis commented #1460
  • May 26 18:42
    tonykaralis commented #1460
  • May 26 17:51
    barclayadam commented #1460
  • May 26 17:51
    barclayadam commented #1460
  • May 26 17:11
    oskardudycz commented #1464
  • May 26 17:11
    oskardudycz commented #1464
  • May 26 16:26
    jokokko commented #1464
  • May 26 16:26
    jokokko commented #1464
Andrew Bullock
@trullock
ok
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?
Andrew Bullock
@trullock
:thumbsup:
Oskar Dudycz
@oskardudycz
hm
I'd like to avoid breaking changes as much as possible
Jeremy D. Miller
@jeremydmiller
Right now it’s just the IField interface.
So only very advanced users would be impacted
I’m more scared of having long-lived branches
Oskar Dudycz
@oskardudycz
Yes, with that I agree
So I'm not against that
What I'd like to also avoid
is the casus of the Angular
Jeremy D. Miller
@jeremydmiller
We’re still spitballing, so nobody’s committed to anything
Oh lord, yeah
Oskar Dudycz
@oskardudycz
They promised to release the Angular 2 that will be "game changer" and won't be backward compatible
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
Jeremy D. Miller
@jeremydmiller
So for a v4 maybe:
  1. 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 the Include() mechanics would be faster
  2. 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
  3. Do the Json streaming story finally because I think that’s a good demo
  4. 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
  5. 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
Oskar Dudycz
@oskardudycz
That sounds like a decent set of functionalities by themselves
Jeremy D. Miller
@jeremydmiller
Let’s just think about it. And see what the other folks think.
Oskar Dudycz
@oskardudycz
I'm fine with releasing them, the only pity is that v4 was supposed to be "The Milestone" :)
but we can change the plan
Jeremy D. Miller
@jeremydmiller
We haven’t committed to anything yet, and “The Milestone” can also be the Duke Nukem Forever or Python 3000 release
Another alternative would be to kick out alpha releases, but I hate fiddling with that from the release side of things
Oskar Dudycz
@oskardudycz
I'm fine with releasing v4
Jeremy D. Miller
@jeremydmiller
We could fudge the SemVer rules for IField and take in most of the Linq improvements for a longer 3.12 release
Oskar Dudycz
@oskardudycz
I think that our users appreciate that we're strict about semver
so probably it's better to just go with v4
Jeremy D. Miller
@jeremydmiller
Then my vote is a quick 3.12, v4 soon after, and v5 is the big event store release
Oskar Dudycz
@oskardudycz
Fine for me
I think that we can squeeze as much as we can till eg. next Sunday
Jeremy D. Miller
@jeremydmiller
Let’s see what everyone else says. I’m enjoying working w/ Marten again at least. The DBAs at my old company stole all my joy for Marten
Oskar Dudycz
@oskardudycz
release 3.12 with what we have eg. at 8th
then focus on Linq
Jeremy D. Miller
@jeremydmiller
Sounds good to me.
Oskar Dudycz
@oskardudycz
Yes, I also appreciate that we got some momentum with you being more active
Oskar Dudycz
@oskardudycz
Probably most of you have seen that, but that's really creepy story https://medium.com/@keivan/the-day-appget-died-e9a5c96c8b22
Andrew Bullock
@trullock
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
Jeremy D. Miller
@jeremydmiller
Yes, but the issue with Marten too is when to accept breaking database structure changes too
2 replies
Tony Karalis
@tonykaralis
@jeremydmiller @oskardudycz your plan sounds like a good one and something we would definitely welcome.
Oskar Dudycz
@oskardudycz
Thank you Tony - appreciate the feedback :+1: