Caché 2016.2 and 2016.3 Field Test Programs

Announcement

Bill McCormick · Aug 25, 2016

This announcement is to inform clients about changes in our 2016.2 and 2016.3 field test programs.

The 2016.2 field test has been extended in order to address important syntax changes related to JSON. Simply stated, the JSON syntax introduced in 2016.1 had several inconsistencies that we did not want to perpetuate. This is now addressed and the updated 2016.2 field test will be published today. Concurrently, the syntax changes and guidance for developers will be posted on the Developer Community shortly. JSON is critically important to our Caché roadmap.

Doc DB has been removed from the field test due to the syntax changes. We have significant refactoring to do in our Document Data modeling code and we did not want to further delay the release of 2016.2 to accommodate that development. This feature will return at a later date.

The extension of the 2016.2 field test conflicts with 2016.3 field test schedule and having two releases in field test simultaneously would result in a delay of a general release for both versions. Since 2016.2 has had significantly more client interest and is closer to a general release than 2016.3, we are cancelling the 2016.3 field test and withdrawing our plans to release it. This will expedite both the general release of 2016.2 and the upcoming field test of 2017.1 later this year. We regret any confusion that this may cause and we expect that it will lead to our releasing higher-quality versions to you faster.

If you have questions or concerns regarding this announcement, please feel free to post them on the Developer Community or contact your Account Manager or Sales Engineer. You are also welcome to contact the Worldwide Response Center (Support@InterSystems.com).

Bill McCormick
Director of Product Management
InterSystems

Ben Spead · Aug 25, 2016

For more details on the JSON changes, see https://community.intersystems.com/post/json-changes-cach%C3%A9-20162 and https://community.intersystems.com/post/writing-forward-compatible-json-...

2 0

Michal Tomek · Aug 26, 2016

Hi there,

is it recommendable to downgrade the 2016.3 FT to the 16.2 FT, now?

We do have two servers with 16.3 and we would like preserving all the settings (and databases as well, of course).

Thank you

Michal

0 0

Herman Slagman · Aug 26, 2016

I opposed strongly against the naming conventions used in the $-systemMethods so I should be happy.

But facing such a backwards incompatibility in 2016.2 makes me very sad. We've planned several major new features in our application all using REST and JSON to be released on 2016.1 very soon. Now we have to review a lot of code and try to decide what to do with them in order to be compatible with future releases. I don't like the suggested macro solution, but it might be the only viable way. We might even switch back to our own JSON implementation which we have used for years.

The most important other issue I opposed to is the interface of the Dynamic array, it is not compatible with the existing COS %Collection interface. Is there any change that will be 'fixed' too ?

3 0

Bill McCormick · Aug 26, 2016

Herman

Stefan can speak to the specific syntax changes to a larger extent then I can. I don't know your timing but I think the best answer is port to the current syntax and go live on 16.2 within a month or so if that is possible. I feel your pain on these changes. But I do believe the end result will benefit everyone in the long run

Michal - if you can wait it might be better to stay on your current kit and then pick up the 17.1 FT as an update in 8-10 weeks?

Michal Tomek · Dec 14, 2016

Hello Bill,

is it now the right time to update our 2016.3 FT server to the 17.1 FT?

+ a question about the Document Model (and the object instance x json conversions) - is it completely out of plans out of the 2017.1 only?

Regards

Hello Bill, yes, we can - no problem. Thank you. Michal

Matthew Gage · Aug 28, 2016

Ouch, this really hurts, but I do see the need.

It's a lot of work whatever approach I take.

If only you were providing a transition with both forms being valid for a period - I'd still have the work to do, but I could spread it out to minimise the pain.

Bill McCormick · Aug 29, 2016

This really boiled down to the band aid removal technique. The existence of a switch implies people are not under any pressure to make changes to their code. It gives them a reason to wait. The longer we left this in the longer we had to support it and the more questions about why something might work in one syntax but not the other. I hate causing partner's pain but in this case the sooner the better.

Ben Spead · Aug 29, 2016

Matthew,

See https://community.intersystems.com/post/writing-forward-compatible-json-... to allow you to write code that will work on both 2016.1 and 2016.2. This is the approach we're using internally to write code that is valid in both versions which has already minimizes our pain. I hope it is helpful to you.

Matthew Gage · Aug 29, 2016

Bill, understood.

Benjamin, That's the conclusion I'd come to - the best option of a lot of bad ones.