Introducing the dev branch

[xukai92]

I think it's about the time to introduce the dev branch to AHMC, for several reasons:

1. The master is stable for a while and it's now high stake of introducing any bugs as many people are using AHMC.
2. A bunch of new, experimental features are waited to be added. Having them merged into master/main directly might not be ideal.
3. It follows the ColPrac guide. DynamicPPL.jl is already doing this; there was also some discussion in Turing.jl (add ColPrac guide Turing.jl#1348).

[xukai92]

So I created the dev branch and also created a PR to put the workflow file to automatically pull changes from the master into dev (#239). I think it would be a good idea to try the dev branch with the 3 incoming refactoring PRs.

[andreasnoack]

A bit late to the discussion here but an alternative is to follow the julia repo workflow where you develop on master and branch off for releases and use backporting.

[yebai]

A bit late to the discussion here but an alternative is to follow the julia repo workflow where you develop on master and branch off for releases and use backporting.

I like this approach, but not sure how much extra dev burden it might incur. Maybe we can give it a try for a few months? If it works well, perhaps we can do something similar for DynamicPPL @devmotion @phipsgabler

[devmotion]

It follows the ColPrac guide. DynamicPPL.jl is already doing this; there was also some discussion in Turing.jl (TuringLang/Turing.jl#1348).

In DynamicPPL a dev branch exists but it is completely outdated and not used anymore. There was no need for it anymore since there were (almost) no experimental and breaking features lately. We just merged everything into master, after updating the version number in the PR accordingly, and released it immediately. This worked fine and also allowed us to propagate new features and bugfixes to Turing very quickly.

For some time we also experimented with a semi-automatic setup that should have updated the dev branch after updating master but it did not work correctly and created a bit of a mess (required manually fixing merge conflicts).

It might still be useful to work on separate branches in DynamicPPL at some point (branching off for releases seems interesting) but currently it is not needed it seems.

[xukai92]

For some time we also experimented with a semi-automatic setup that should have updated the dev branch after updating master but it did not work correctly and created a bit of a mess (required manually fixing merge conflicts).

Ahh. I didn't realise this. I'm actually using the auto-merge script from DynamicPPL. Maybe for this reason doing what @ andreasnoack suugests is a btter alternative? The dev branch is still new and we can safely swtich to the master-release-backporting alternative I think.

[yebai]

The dev branch is still new and we can safely swtich to the master-release-backporting alternative I think.

Yes, let's experiment with the approach suggested by @andreasnoack and see how it works.