Closed xrotwang closed 5 years ago
Oh, and it also makes for a lot simpler RELEASE instructions :)
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.
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 ...
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 master
are releases by definition. Let me guess, this is BEAST 2.5's fault?
Hm. good guess. How do we pin BEAST versions in setup.py? :)
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
?
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 .
That's all I planned to do. But if @Anaphory has any WIP branches split off from develop this will cause him headaches, right?
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 .
It is done! Well, the merge and release and upload to PyPi is.
Feel free to immediately close this issue. But ... For
clld/clld
I switched from the gitflow development workflow to simply developing onmaster
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 fromdevelop
. I see long living branches as a recipe for problems now, rather than a solution for anything.