Dear All,
concerning the freeze+release of DYNARE 4.5, I would like to
finish/PR:
- shock decompositions + plot_shock_decomposition utilities;
- some (minor) extensions to the parallel [not yet the submodule,
which would be a major change, but an option to tell how many
threads to assign for each slave, since currently we give a
singleCompThread which might be inefficient given the latest
desktops featuring a large number of cpu's]. I would say this
requires a new option for the dynare.ini file for the node.
I have to open an issue on github
- there are a couple of small issues in posterior sampling
analysis: in particular it seems impossible/difficult in the
current configuration to run, e.g., posteriorIRF with
load_mh_file=1 and mh_replic=0, unless the oo_ stored in _results
if perfectly fit [which is almost never the case I must say ... ].
Moreover, current parallel configuration for posterior subdraws
and plots does not look appropriate any longer.
- I think it would be useful to have an option for not to fill in
oo_.FilteredVariablesKStepAheadVariances, e.g. by using
options_.filter_covariance [I have a possible PR for this in
store_smoother_results].
- I need to check my local copies for further small adjustments
here and there.
- I would like to fix #838 #1016 [and associated #789] #1170.
What would be the DEADLINE before freezing DYNARe 4.5?
many thanks
best
Marco
-- Marco Ratto, Finance and Economy Unit Joint Research Centre European Commission, TP 361, 21027 ISPRA(VA), ITALY Tel: +39 0332 78 3794 Fax: +39 0332 78 5752, marco.ratto@jrc.ec.europa.eu http://www.macfinrobods.eu/
Hi, I also vote for the second option. But I would prefer not to take it from the master branch... If I create a branch 4.5 this week (I was about to do it) would it be fine with the Debian's deadlines. Before the official release we need to fix (or merge): - #1201 (the issue with nested parenthesis limit in matlab). - Fix the interface for (stochastic) extended path. - #1287 (I need to push the fix I made somewhere). - PR related to the documentation. I am working on the windows build. We target Octave 4.2, but we wont't have time to fix all the bugs before the release of 4.5.0. This will have to wait 4.2.1. Following issues will wait another release: - #1175 is related to the changes that revealed the problem in #1201. Normally we don't need this anymore... This is not a blocking issue. - #419 - #841 - #1045 That said, I am also fine with option 3. Maybe we should have 4.5.x (and 4.y.x) in experimental. I ;have no idea of the amount of work necessary to build a debian package... Best, Stéphane. On 28/11/2016 15:32, Johannes Pfeifer wrote:Hi, I would go for Option 2. We continuously keep delaying the release of a new stable version, although the current unstable version is a lot more "stable" than 4.4.3 and fixes several critical bugs. What is blocking the release of a new stable version? From my perspective, it is 1. Bug #1201 needs to be fixed. That is probably the critical issue here. 2. #1175 should be taken care of. 3. #419 needs to be taken care of (proposed solution exists). 4. #1287 should be dealt with (easy workaround available). 5. The outstanding pull requests should be taken care of, particularly the documentation ones. 6. There are various issues with the build system for Windows we need to solve when we want to release a Windows version (#1179). 7. Octave 4.2 support does still not fully work, but I don't consider this critical (#1307). 8. #841/#1045 would be nice to have, but is not essential. There are various smaller things we could always fix in 4.5.1, including issues at the back end of the above list. Best, Johannes Am 28.11.2016 um 14:34 schrieb Sébastien Villemot:Dear all, The next version of Debian (labelled "Stretch") will be released in spring 2017. Like all Debian releases, it is expected to be maintained for 3 years, which means until 2020. Given the tight release schedule, we must make very quickly (i.e. in the coming days) a decision about the status of the Dynare package in that release. There are basically 3 options: 1. Ship Dynare 4.4.3 in Debian Stretch. Pros: this is the latest stable release, and Debian usually ships stable releases Cons: it is getting quite old 2. Ship a snapshot of Dynare Pros: fresh codebase Cons: hard to decide which git commit on which to base the package; possibly buggy 3. Drop the package (from the stable release, not necessarily from Debian sid/unstable) Pros: avoids shipping an old or a unstable codebase; makes it clear that the user must make its own decision Cons: less user-friendly All 3 options are fine with me, but I think you are in a better position than me to decide. Please let me know what to do. Best,_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev