Provide documentation for the upgrading to 4.6

Between 4.5 and 4.6, many structures in M_, options_ and elsewhere which used to be character vectors are now cell arrays. Other things have changed in a backward-incompatible way.

We need to compile the list of all those structures, and document that change in the release notes.

changed title from Provide documentation and a compatibility layer for the move to cell arrays in various structures to Provide documentation and compatibility layers for the upgrading to 4.6

changed the description

mentioned in issue #1197 (closed)

Also need to document the changes and maybe add a compatibility layer for stoch_simul, discretionary_policy and simult_ (see #1197 (closed))

And there is also the macroprocessor change for arrays, like [1:2] (see preprocessor#6 (closed)).

Done

added decision label

added discussion label

Following up on our discussion at mattermost, I disagree with providing a compatibility layer for stoch_simul, discretionary_policy and simult_. There are very good reasons for not having oo_ (and others) global.

First of all, having globals will prevent future parallelization. For example, it would make a lot of sense to have simult_ parallel when doing GIRFs with a lot of replications. Having a compatibility layer will prevent this or lead to cryptical error messages that users will not understand. Second, the globals have historically caused a lot of harm. I have seen teaching codes by important people that relied on the globals and resulted in wrong results. The compatibility layer would allow people to continue with this bad behavior instead of forcing them to update their code. Updating should not be that problematic, because the changes are straightforward and we have always provided good support to users.

Regarding kicking the can down that road to a future release, I think 4.6 is a good version to remove globals as far as possible (dynare_estimation and _steady_state.m-files come to mind). It will introduce multiple breaking changes like the macroprocessor and the cell arrays that will force users to modify legacy files in any case. At the same 4.6 will not introduce any important bug fixes relative to 4.5.7. So users have a reliable legacy version available that could be used if they want to run older codes.

Also need to document the breaking change in irf_calibration and moment_calibration (see preprocessor#12 (closed))

Done

changed title from Provide documentation and compatibility layers for the upgrading to 4.6 to Provide documentation for the upgrading to 4.6

changed the description

added documentation label and removed decision discussion labels

We’re giving up on compat layers (see #915 (closed)). We should focus on documenting the changes.

The interface change for old-style steady state files should be documented (see !1673 (merged)).

Done

@sebastien What is the best work-flow for this? Should we start a Wiki? In the past, that was a starting point for the text file announcing the changes. But I guess that this time, a pure text-file will not be sufficient as we may need some form of syntax highlighting or color schemes.

Yes, I think a wiki page is appropriate. In Ispra, @MichelJuillard told that he would initiate it.

The work is proceeding at this page: https://git.dynare.org/Dynare/dynare/wikis/BreakingFeaturesIn4.6

Is there a reason to do this instead of folding it into the New Features page (perhaps renaming it to Release Notes)? Matlab does this for their release notes under a section called "Functionality being removed or changed."

Note for example the tags that look like Matlab's that I have introduced for the macro processor changes...