ETA for Release 5.2

Using FoundationDB
1

It is a bit of an awkward situation for us since we have already internally be using AppendIfFits in the 3.x codebase and we can’t really “upgrade” to 5.1.5 since it doesn’t (5.2 seems to have it officially supported again). So the question is whether there is an ETA for 5.2 at this point?

2

The biggest feature of the 5.2 release is that it allows backup and DR to share the same mutation log. This enables clusters which are running both backup and DR to only write 2 copies of every mutation instead of 3.

We are in the process of adding upgrade support to DR for this, so that running DRs continue to work through the upgrade to 5.2. It is passing simulation tests, but we still need to do a few real world tests. I am optimistic we will be able to release 5.2 in a few weeks.

2 Likes
3

I see 5-2 was merged to master (https://github.com/apple/foundationdb/pull/443), but the download links (or at least the rpm files referenced) are not valid yet, and https://www.foundationdb.org/ isn’t reflecting that change. Are there expectations around releases somewhere?

What needs to happen so that all the tagged releases (i.e. https://github.com/apple/foundationdb/releases) get built/distributed/published? Is there anything that the community can do to help there?

2 Likes
4

We are still testing the 5.2 release, and we will publish it to the website once the testing is complete. You may have noticed that we have already done three patch releases since the first tagged 5.2.0 release; this is a result of us finding and fixing some problems our testing turned up.

Things look pretty good right out, so it should not be long before we are comfortable making 5.2 available on the website.

5

Thanks Evan. I appreciate the context.

6

I guess I’d also like to point out that we merge our release branches into master fairly regularly. (The master branch is usually for a release that will happen after whatever the current release branch, so if we make a change on a release branch, we then merge it into master so that that change also shows up in the final release of that branch, if that makes sense.)

I’ve added a PR (#467) with some text that supposed to explain our release process (and I’ve also edited the existing 5.2 release tags to indicate that they are pre-release builds, i.e., that we have not yet finished our internal vetting process).

If you’re looking for something to do to help with the process, I suppose you could try deploying versions of FDB that you’ve built from the 5.2.3 tag (let’s say) and see if you run into any regressions. If you’d rather not do that (which is reasonable enough), then I guess the best thing is to just sit tight for the release?

7

Thanks the pre-release tag on Github most directly addresses the missing context i had originally

I’m steadily working through evaluating FDB over the next month for one particular use case and i’ll share feedback as i have it, but I’m afraid as a result I won’t be able to be much help in terms of detecting regressions yet.

8

Oh, yeah, that’s fine. We’d definitely appreciate any feed back (especially if things changed unexpectedly with 5.2), but our internal review should catch most things anyway. Happy evaluating!