Veuillez noter que la technologie utilisée pour notre site web n'est pas supportée à 100% par Internet Explorer 6 ou inférieur !


FAQ - R-Release

Frequently Asked Questions about R-Releases

How are new features developed in R-releases?

Each new feature is developed exclusively in the main development branch. Each feature is developed in a way that allows us to deactivate it. Then, for each feature, we perform automated and/or manual testing according to the feature type. (We give priority to automated testing, which can be re-performed anytime.)

Every 3-4 months, for example, we create a new 4D v14 Rx branch from the main development branch. When the branch is created, only the features that are “ready” (i.e 100% tested) are kept. We deactivate all other features for which testing is not complete, even if it is nearly done. Any feature that is “almost finished” will be postponed until the next R-release.

The concept is to deliver at a certain date only the features that are ready, so that we really concentrate on software quality over delivering more features that are not yet fully finished.

R-releases and bug fixes: Are the same bug fixes in 4D v15.x and in 14 v15 Rx?

The answer is no. However, R-releases do of course include bug fixes. But it is just a matter of synchronization. The reason for this desynchronization is actually due to the R-releases development process itself.

Release notes are provided for both R-releases and minor releases, so you can know which bugs have been fixed in a given release.

To go further into details, here are the different steps when a bug is fixed in 4D v15.x (same for 4D v14.x):

  • A bug is been reported in, let's say, 4D v15.x
  • The bug is investigated and a fix is performed on the main development branch.
  • The bug fix is then tested and validated by our test team, always on the main development branch. The testing can take a few days depending on the type of bug and its potential impact.
  • Once the fix has been validated, it is integrated to the 4D v15.x branch. Then a Nightly Build is released the following day in the Nightly Build forum.

When we are getting closer to a public minor release shipment, the branch is frozen – usually for a 3- to 5-week period. "Frozen" means that there are no more bug fixes integrated into the branch, and only manual testing is performed. If somehow a previous correction leads to a secondary issue (that wasn't detected during automatic testing), a new fix is performed on the initial bug fix, or the initial bug fix code is removed. Then the version is released as a minor release.

Each code change can potentially lead to new issues, hence those three weeks of manual testing (with two additional weeks planned in case any blocking issue occurs requiring changes, which we would need to test again).

Now, regarding new feature implementation, the development is performed exclusively in the main development branch. For example, the 4D v15 R2 branch has been created from the main development branch, and this branch was created back in February 2014. Therefore this branch includes all new features implemented from 4D v15, as well as all bug fixes performed on the main development branch up to that date.

The features that are not stable/mature enough are deactivated, and then the branch is frozen. Absolutely nothing comes in (no last-minute, tiny code changes) except bug fixes related to new features or major bug fixes (as showstoppers, data corruption, etc.). Meanwhile the version is deployed for production on our internal systems. This is how we ensure stability in R-releases.
This is a concept which that Google, for example, followed for Chrome. Delivering an update with known issues is better than releasing an insufficiently tested version with potential other unknown issues. This is drastically different from the usual method, wherein you fix as many issues as possible, as quickly as possible. This is where the short cycles come from.

As another example, the 4D v14 R5 branch includes all of the bug fixes included in the main development branch up to end of its time of release. Those fixes have been tested for several months, not just for a few days like 4D v15.x (in Nightly Builds). This is how we can ensure that a given bug fix has not introduced any instability. The version will then be slated for delivery three months later.

How do Nightly Builds fit into the story?

Hotfix versions were introduced before we started to provide access to Nightly Builds. At the time, we had an automated build process, but only basic automated testing.

A hotfix version was running though a 3-5 day period of manual tests (compared to 3-5 weeks for a minor release).

From 2013-2014, we started investing heavily in automatic testing. The build process now runs once per hour (done from a cluster of computers automatically creating 4D v13, 4D v14, 4D v14 Rx, main, versions, and so on, just as with Wakanda, for Mac OS X 32- and 64-bit, Windows 32- and 64-bit, Linux 32- and 64-bit – and this whole job for each available language, like English, French, German, Japanese and so on. The versions created are automatically distributed to a cluster of test computers, where they run not only unit testing but also many fully automated tests with 4D applications. We have enhanced 4D for this purpose, with features such as FORM SCREENSHOT developed with this kind of testing in mind.

As a result, Nightly Builds have achieved a level of quality equal to that of previous hotfixes, in many cases even better.

Of course, we continue to enhance the process. We are also designing new commands on a regular basis to ease the automated testing, and naturally these commands will also be available for our customers.

Will Nightly Builds be available for R-releases?

Yes. Nightly Builds will be provided, but only if a major issue is found in a R-release: for example data corruption issues, major crashes, etc.

Unlike 4D v14 and 4D v15 Nightly Builds, R-release Nightly Builds will not be distributed through the 4D forum but using the same download link as the official R-release. (The link is accessible from your 4D Store account.)

Are R-releases really meant for deployment?

Absolutely yesR-releases give you the opportunity to see what the new features of the next major version will be, play with them, and give us feedback – but it's not only that.

In recent years, we started beta testing early, and hopoing for feedbak early in the development cycle, but it didn't work. Developers were just taking a quick look at the new features and that was it. Developers typically wait for for .2 or .3 releases, only then starting to test and learn that some new features are not fully usable as they are missing options or anything to be useful in their applications. 4D did 95% of the job, but 5% of what it would take for the feature to be fully usable was missing.

At that time we were already close to beta for TNV (The Next Version), so it was already too late to take customer feedback into account. The result is that a feature became fully usable over two or even three major releases later.

Thus the overall quality was not perfect, as so many changes were made at the same time.

If you take a look at computer news sites and blogs, "continuous delivery" is a prime topic these days, and nearly everyone agrees that it is the key to improve quality to get rid of the dot-zero problem (i.e. having to wait for .2 or .3 versions before going into production).

A key to continuous delivery is that it only works if the end user is really using the product, not just testing it.