Replies: 1 comment
-
Hi. As we develop these standards, we are talking with the various related development groups to make sure that we're considering the future direction, and to avoid making recommendations that are "dead ends" I like the idea of advice on how to handle multiple releases. My "first order" recommendation is that because MATLAB is compiled "on the fly", you can make decisions at runtime based on the running release. For example, my Climate Data Store Toolbox does that here, deciding if it can generate a report depending on what release we're using. I'm going to rename this discussion to be a little broader. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Mathworks currently advertises using mpm in the matlab-dockerfile readme:
https://github.com/mathworks-ref-arch/matlab-dockerfile/blob/main/MPM.md
Assuming Mathworks is going to continue standardization of toolbox to 3P developers, Mathworks should ensure that this toolbox design documentation aligns with further internal mpm development.
For example, if a 3p developer wants to implement features of a new release but still maintain compatibility with older releases, they may want to take advantage of the
--release
flag:mpm install MyCoolToolbox --release=R2023a --doc
How would this current documentation handle releases in the same repo? Perhaps create tagged branches? separate by folder?
Does the --doc align with the current documentation folder structure in this repo?
Beta Was this translation helpful? Give feedback.
All reactions