One more week sounds good to get ode things in with a bit more time.
Whatās so important that we have to disrupt the release schedule? The whole reason we have a schedule now is to prevent every release from becoming a negotiaton about what needs to go in.
What if that takes more than a week?
I guess I didnāt think there was anything that critical about the 13th.
I do think the interface changes are significant and worth a weekās wait. I still intend to finish ODEs by the 13th anyway, but I thought it doesnāt hurt to be a tiny bit conservative (I donāt want to be asking for an extension on the 12th).
If ODEs arenāt done by the 20th, I donāt mind bouncing them to the next release.
Could use a review of the ODE docs: https://github.com/stan-dev/docs/pull/213
And the design-doc: https://github.com/stan-dev/design-docs/pull/20 if youāre volunteering to help keep us on schedule :P.
There isnāt. But there is something critical about having regular releases rather than negotiating them each time.
The point was to not have a schedule and just release whatever we had every three months.
Iām definitely not the best person to be reviewing ODE docs or PRs, but can give it a shot if youāre despearate. (Ping me via emailāI only check into Discourse every few days.)
I think that weāre well within the spirit of regular releases here. Rok listed the projects that were already under active development - maybe some of them wonāt be completed, but for the folks whoāve been going all out on getting stuff in, thereās no reason not to provide an extra week to get stuff in, because if something really is close to completion, itās a shame to lose the momentum.
we donāt want to play the ācome back next weekā game forever - if something canāt be done in an extra weekās time, chances are 2 extra weeks arenāt going to be enough, either, and this should be a teaching moment about better estimating time to completion. (especially useful when fielding the question āhowās the dissertation goingā)
1 Like
That was my thinking yes. I think both variadic ODEs as well as vectorized binary functions would be a great get for the expense of a delay for a week. But obviously if other do not agree, then we should not force it.
I would then propose RC on the 20th and if there are no bugs release on the 27th. For minor bugs we dont need to do a RC2. If a larger bug is found we do a RC2 and prolong the RC period.
I think we should make issues on the repos so all developers are aware of the schedule. So we should decide in a day or two what to do.
2 Likes
I just reviewed all that material. Lotās of work, but I think we are basically there (everything except stanc3 bits is what I have covered here).
The regularity of regular releases is important, I think.
Is there a way to have our cake and eat it too? Could we have a feature freeze period which gives us some part of this ācome back next weekā slack? Or perhaps a beta release a month before the release candidate release?
This strikes me as a problem that likely has a good solution.
Thereās not a good solution when thereās slack in the system at the end to say āhang on, Iām not done with this important featureā. Thatās where weāre at now.
Iām in favor of just releasing. But itās not that big of a deal to me if everyone wants to barter for release times again like we used to do. I just donāt want to be involved.
1 Like
we have a 1-week feature code freeze to test release candidates already - cf:
where next Monday == July 13th.
Iām wondering if there might not be a correlation between the length of the feature freeze and meeting the release deadline. Surely if the feature freeze window was 2 months (instead of 1 week), the release deadline would certainly be met, right?
This was discussed more at the weekly meeting and no one opposed moving the release up a week. We also have accumulated a fairly large docs depth that would also benefit from that additional week.
Given that we also added a few days last time due to some discussions of whether something is a bug or not, I am hoping there wont be too much of a blowback from this postponement.
I am going to make the issues on the repos so everyone is notified.
Not sure if there is a misunderstanding here. Feature freeze just means that any ānew featureā PRs will no longer be merged. You are probably talking about a specification freeze I am guessing.
Yes, some kind of more general freeze. Only critical bugs can be fixed. The description of Ubuntuās beta freeze policy gets you some sense of this sort of policy: https://wiki.ubuntu.com/BetaFreeze .
Yes, that is what we do for a week with cmdstan/stan/math/stanc3.
According to wiki
its named a feature freeze. Obviously there are different names to this at different project.
2 Likes
Well, I guess what is happening is clear to the immediate participants.
As an outsider, it looks like the delay isnāt related to a critical bug. (āI do think the interface changes are significant and worth a weekās wait.ā)
We generally do the feature freeze.
What I proposed above is that we delay the start of the feature freeze in order to get some additional stuff in.
2 Likes
At the meeting no one opposed moving the freeze to the 20th and the release to the 27th. There is some opposition here though, so not sure how to proceedā¦
A few stanc3 issues popped up now that rstan checks whether the users model compile with stanc3 that would also be good to get resolved for the release.
We decided at the Stan meeting that its fine to move by one week. So letās stick to that.
We are really not suggesting to move back to the past where we took forever between releases. The extra week is needed to get some things in 2.24 without burning devs weekend time, which is a good thing.
Maybe we add to the āofficialā release procedure that on the last Stan meeting before the freeze this is up for discussion. As I recall you basically did point this out earlier, so that is all fine.
Itās still going to be a July 2020 release - and itās going to be a major one!
2 Likes
Perhaps some language could be added suggesting that disrupting the schedule is not something which should be encouraged as it undermines the goal of regular releases?
Iām invested in the regular release. One of PyStan 3ās goals (see Finalizing the Interface Guidelines Design Doc) is to have a release within 48 hours of a Stan release. Having to worry about the actual vs. the planned release date imposes an additional burden which I would prefer not to have to deal with.
1 Like
The release is already now not set in stone to happen in a clocked way. We do have a week of feature freeze to nail down critical bugs - but that window of one week is to make sure we get them all with a decision to be made if the week was sufficient shortly before the release.
The default will be to release according to schedule, but we have already now intentional flexibility to some extent in order to avoid those many .1 releases which we had in the past.
Like I say - itās going to be a July 2020 release (almost for sure).
EDIT: That is my understanding of the process as we handled it like this in the past.
1 Like