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