dask / community

For general discussion and community planning. Discussion issues welcome.
21 stars 3 forks source link

Release cadence #200

Open fjetter opened 3 years ago

fjetter commented 3 years ago

This ticket is to not derail any changelog related discussions going on in https://github.com/dask/community/issues/199

Xref https://github.com/dask/community/issues/101

jrbourbeau commented 3 years ago

Copying over @jakirkham's related comment from https://github.com/dask/community/issues/199 here...

don't understand how the release cadence affects our ability to fix regressions. In my mind, we agreed to just release where we are at every 2 weeks

I believe two weeks are not sufficient to find and fix the regressions. Due to stability problems in dask/distributed we recently needed to delay multiple releases because we didn't manage to fix them in the given time.

On the flip side releasing less frequently could mean more regressions accumulate in main (as others are only testing the latest release) and we only find out about more of them later (once we finally release).

jsignell commented 3 years ago

I misunderstood what you meant about the cycle being too short to fix regressions. It thought you meant regressions that were introduced in a previous release. In which case releasing again, even if the regression isn't fixed, doesn't necessarily make things worse. It seems like what you were intending to consider are the cases where the regression is only on main (unreleased) and we are trying to avoid releasing any versions that contain the regression.

To fix that I think we need to think about introducing a code freeze before releases. Maybe that would end up resulting in a longer release cycle, but the main mechanism for preventing undiscovered regressions from entering release has to be a freeze right?

quasiben commented 3 years ago

I think it's also worth linking an older discussion from last year where it was proposed to increase releases: https://github.com/dask/community/issues/84. The community and focused uses cases may have shifted since that was introduced but the discussion is worth reviewing.

jakirkham commented 3 years ago

It's good that you raise that Ben.

Several discussions evolved out of that may be worth revisiting as we figure out how best to improve the release process. In particular we observed there were a few common needs:

This motivated a few discussions most notably how CalVer was implemented here ( https://github.com/dask/community/issues/100 ). These also came up:

Also more recent, but conceptually related:

While there are still needs for each of these cases, there has been some effort to address them with CalVer. It may be worth revisiting how to address those as they get at the sticky issues that make releasing challenging.