Drop develop branch?

[xrotwang]

Feel free to immediately close this issue. But ... For clld/clld I switched from the gitflow development workflow to simply developing on master and tagging releases appropriately. I find this now a lot simpler and - if combined with branch protection - probably even "better" than doing big merges every once in a while from develop. I see long living branches as a recipe for problems now, rather than a solution for anything.

[xrotwang]

Oh, and it also makes for a lot simpler RELEASE instructions :)

[Anaphory]

I have voiced the semi-related issues concerning the fact that devel and master are only loosely related before, which for me is an argument in favour of dropping devel.

On the other hand, I know that my programming is often not completely clean, so I somewhat value the buffer space the develop branch gives me for merges that are not perfect and should not go into master without prior cleanup.

[xrotwang]

Regarding space for unfinished work: You are free to use any number of branches you want to - plus possibly the master branch of your fork. The reason I created this issue is that I set up beastling on a new machine, cloned the repos, installed the dependencies, ran the tests - and had errors. Then checked out develop and the tests passed. This mismatch is somewhat irritating - in particular in the combination with master failing and develop passing ...

[lmaurits]

Yes, I am pretty favourably inclined to this idea. I cargo-culted the "successful git workflow" model or whatever it was called when I started using Git for large projects, and have regretted it since more than once. Let's streamline things after the next release.

I'm concerned to hear that master is failing, under the model we're supposed to be using it should always be in a production ready state, as tags on masterare releases by definition. Let me guess, this is BEAST 2.5's fault?

[xrotwang]

Hm. good guess. How do we pin BEAST versions in setup.py? :)

[lmaurits]

So, how do I do this in a way that causes minimum inconvenience to you guys? Do either of you have any substantial uncommitted in your local versions of develop?

[xrotwang]

I'd say merge develop into master, make a release, fix release instructions and then delete develop.

Luke Maurits notifications@github.com schrieb am Mo., 29. Juli 2019, 16:35:

So, how do I do this in a way that causes minimum inconvenience to you guys? Do either of you have any substantial uncommitted in your local versions of develop?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lmaurits/BEASTling/issues/230?email_source=notifications&email_token=AAGUOKAP75VAGCOGLBHSY23QB352VA5CNFSM4GGNO2J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3A475I#issuecomment-516018165, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGUOKANVVO5GRI5A6IWJJDQB352VANCNFSM4GGNO2JQ .

[lmaurits]

That's all I planned to do. But if @Anaphory has any WIP branches split off from develop this will cause him headaches, right?

[xrotwang]

The worst case scenario would be rebasing these changes on the new master, I think.

Luke Maurits notifications@github.com schrieb am Mo., 29. Juli 2019, 16:46:

That's all I planned to do. But if @Anaphory https://github.com/Anaphory has any WIP branches split off from develop this will cause him headaches, right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lmaurits/BEASTling/issues/230?email_source=notifications&email_token=AAGUOKCCK2DQVEC2D3BZPMLQB37DVA5CNFSM4GGNO2J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3A6DYA#issuecomment-516022752, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGUOKAGRNAF2X4FN6AWOTDQB37DVANCNFSM4GGNO2JQ .

[lmaurits]

It is done! Well, the merge and release and upload to PyPi is.