Crease a `dev` branch for breaking changes about dynamicppl.jl HOT 12 CLOSED

I think the process we should have is to do all the development in dev and cherry pick any bug fixes or quick fixes into master before a release, so that master doesn't change as much as it does now.

from dynamicppl.jl.

Since many commits affected the same files and functions, I guess it's also tricky to actually cherry pick commits and still ensure that nothing is broken and we don't reintroduce stuff that was removed at some point.

from dynamicppl.jl.

Nope, go for it.

from dynamicppl.jl.

Sounds reasonable, we started using the same setup for MCMCChains some time ago. However, it's not ideal yet, I noticed that we have a bunch of fixes in the master branch that are not included in the dev branch. I'm not sure what's the best way to handle it, maybe we should just merge master from time to time or cherrypick these commits? Or just merge the dev branch often enough 😄

from dynamicppl.jl.

I agree.

from dynamicppl.jl.

I will create a dev branch and reset master to the latest release then cherry-pick non-breaking changes.

from dynamicppl.jl.

Is this necessary, can't we just update Turing and start using a dev branch from now on? Many changes were just internal or should only affect Inference.jl. And AbstractMCMC 1.0 requires to update Inference.jl anyways.

from dynamicppl.jl.

Sounds good, let's update Turing instead then. There are about a 100 commits or so since the last release so yes cherry-picking will be a nightmare.

from dynamicppl.jl.

Does anyone here object to a DPPL release?

from dynamicppl.jl.

JuliaRegistries/General#13254

from dynamicppl.jl.

I guess this is done now? At least if we actually remember to use the dev branch :)

from dynamicppl.jl.

Yes, and I think lately we actually started using the dev branch, so I'll close this for now.

from dynamicppl.jl.