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,
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:
- 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
- Ship a snapshot of Dynare Pros: fresh codebase Cons: hard to decide which git commit on which to base the package;
possibly buggy
- 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,
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
- Bug #1201 needs to be fixed. That is probably the critical issue here.
- #1175 should be taken care of.
- #419 needs to be taken care of (proposed solution exists).
- #1287 should be dealt with (easy workaround available).
- 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:
- 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
- Ship a snapshot of Dynare Pros: fresh codebase Cons: hard to decide which git commit on which to base the package;
possibly buggy
- 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
If you are able to release Dynare 4.5 quickly, this is of course the best possible course of action.
The deadline for having the package uploaded to Debian unstable is January 25. But given that I need some time to update the packaging and to discover potential build problems (especially on exotic architectures), I need some extra margin. Basically if you can make the release by Christmas that would be ideal.
I also forgot to mention that Debian Stretch will ship with Octave 4.0. The 4.2 version was released too late (Octave is a package much more complex than Dynare, with shared libraries, and the deadline for such an update has already passed).
Best,
Le mardi 29 novembre 2016 à 11:00 +0100, Stéphane Adjemain a écrit :
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
- Bug #1201 needs to be fixed. That is probably the critical issue here.
- #1175 should be taken care of.
- #419 needs to be taken care of (proposed solution exists).
- #1287 should be dealt with (easy workaround available).
- 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:
- 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
- Ship a snapshot of Dynare Pros: fresh codebase Cons: hard to decide which git commit on which to base the package;
possibly buggy
- 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
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
-
Johannes Pfeifer -
Marco Ratto -
Stéphane Adjemain -
Sébastien Villemot