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/ On 11/29/2016 11:00 AM, Stéphane Adjemain wrote:
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