How do we communicate the 4.0 branch with our users?

Development & Design
1

I would like to clarify the status of the 4.0 branch and release and how visibile to the general public and our users it should be.

I previously understood that we would release a 4.0 version at some point to integrate work done by @antonin_d (some users have a similar understanding). The 4.0-alpha1 release was a first step in that direction. However, following recent comments here and here I wonder if my understanding is still correct and if we should actively communicate around it. I'll be happy to update my document based on the consensus here.

Thank you.

2

I think the consensus so far is that we:

  • rename the current 4.0 branch to something else (say delta)
  • get some sort of agreement of how we want to schedule breaking changes we want to implement soon

Out of this discussion, maybe the new data processing architecture I have been working on will indeed be released as 4.x, or we could decide to introduce other breaking changes first (in which case it could be released as 5.x, 6.x… or not at all).

For our communication with users, I would say: we don't know yet when and how those things will be released.

3

Thank you for the clarification. I'm happy to follow those guideline in future communication.

4

There will definitely be a 4.0 release - the only things in question are schedule and content. :slight_smile: Hopefully no promises have been made or expectations set with users, although they will likely have come up with expectations of their own.

I agree with what Antonin said and, if more detail is needed, here's how I'd position things:

  • 4.0-alpha1 was a preview release to showcase some of the work in progress and get early feedback, but doesn't necessarily represent how the features will be released - some of the features may appear in 3.x releases before 4.0, some in 4.0, and some may appear in post-4.0 releases
  • The integration branch which was being used to test a variety of features together was originally named in a way which implied everything would appear in a single release, but we haven't decided on this yet, so the branch will be renamed, as Antonin said, to avoid that implication.
  • Some of the features which have been developed are compatible with the existing 3.x software and Antonin has been working to get those merged for release, potentially before 4.0
  • Big data set support was one of the primary focuses of the next gen work and that remains an important goal
  • There are additional potentially "breaking" (ie incompatible) changes being considered, such as improvements to the extension developers ecosystem, which are under consideration and we're trying to figure out how these various changes get bundled/ordered into releases.
    While we're discussing expectations, how big is "big data" in the context of what users have requested as a goal? Are there any performance expectations/goals?

I think we're actually on a path to get more features into users hands earlier than a "big bang" release would, but we remain very capacity constrained. In terms of user communication, I think one lesson is to defer feature<->release binding, so we should talk about "large project support," "resizable columns," or Feature XYZ, rather than 4.0, 5.0, etc.

Tom

1 Like
5

Totally. Talking about Features is how we should communicate with our User Community.
"Our upcoming release will feature Large Project support that addresses the need to work with gigabyte+ sized datasets." Large Project support was really all that I cared about at this point. And my expectations have been exceeded as Antonin can tell you. I was able to import and parse many of my large CSV files (2-5 gigs each) and work with Faceting and Transforms and Export.

I'd rather that we try NOT to squish all the shiny bells and whistles we've been working on, if we can avoid it. And just introduce them over time with Feature releases. If the dev merge effort gets complex, then just Feature Flag them so that both devs and users win out? We can take our time here on releasing each feature.

For branching, which is the original context of this discussion really. I don't have any opinions and think it's totally fine to have many feature branches and merge them into trunk with feature flagging.