I thought one of the changes for the new release model is that previous R releases would get bug fixes. 18R2 was released in April and 18.2 in June. I see 18.2 fixes on the R3 fix list but I don’t see anything to indicate 18R2 is getting bug fixes.
When released 18R2 became frozen and no fix to expect. Is it your question?
Yes, I thought that changed with the new release model. That is, older R versions would get bug fixes which was not the case with version 17 and prior. I was going to deploy an R release for the first time because of this. If upgrading to the next R release is the only way to get bug fixes (as it was with 17), then I’ll probably have to stay with the LTS version. Maybe I just misunderstood.
18R2 seems to be very stable and is the good version if you need 4D Write
Yes, we are using v18R3 but many new features had bugs so we are glad, that 4D fixes bugs in v18R3 very quickly.
Yes, I want to deploy with 18R2, but there are some important bugs that are now only fixed in 18.2 and 18R3. Taking the next R version will always be a risk for stability with first implementation of new features. It would be helpful if the 18 LTS bug fixes were also applied to the current released R version (not in beta).
Yes, I want to deploy with 18R2, but there are some important bugs that are now only fixed in 18.2 and 18R3.
With LTS version, in average every 3 months we deploy the next minor version with Bug fixes.
With Feature Release version, every 3 months we deploy the next version with Bug fixes and new Features.
Taking the next R version will always be a risk for stability with first implementation of new features.
The development concept is to add only new features after long testing (in our case 3 months internally, 3 months externally/Partners). So far this worked quite well. Nothing is perfect, sure, so it did happened 3 times since we started with R Releases (v14 R2) that a new feature introduced a show blocker bug for an existing functionality. In each case we delivered a kind of hot fix for the release.
Please remind that every bug fix is a code change, which could introduce new bugs just by fixing something else. This happened lately several times for both Apple and Microsoft, forcing them to release another update just a week later.
For the OS this is “easy”, as the end just “just” needs to update again (except if the computer does not even boot anymore).
For 4D developer it is more uncomfortable, as they need to download, build and then deploy to their own customers, which needs to download/install again.
As result, more and more companies consider a different approach.
We learned that from Google (Chrome). Bug fixes needs as much testing as new features, they need to be considered as “dangerous”. As result, bug fixes released in Feature Releases are tested for 3 months. There are sometimes exceptions, but those are especially carefully tested (both code review and manually, in addition to automatic testing which happens anyway).
Thank you for taking the time to clarify how it works and the rationale.