Using the future package to aid in determining symbols and packages to export about foreach HOT 8 OPEN

@HenrikBengtsson do you think there's still a need for different "master" and "richcala/foreachFutureTake3" branches? Just trying to rationalise the structure.

from foreach.

Yes, I think for a bit longer. The long story...

My suggestions:

1. For now, don't drop branches unless you know for sure you don't want them. They add to the clutter but otherwise just pointers in git. If you buy into the below, you can just rename/reorganize into that model. That will clarify things.

2. Look into the https://nvie.com/posts/a-successful-git-branching-model/. The gist is that master always reflects you latest release (=what's on CRAN). You never commit to master - only merge into it. Continuous development and bug fixes goes in to the develop branch. Major updates like the recent 'local' and the 'globals-by-future' subprojects can be developed in 'feature/local' branches. When these are "closed" you merge them back into the develop branch (="to become the next release").

3. There's a shell tool git flow (https://github.com/petervanderdoes/gitflow-avh) that automates all of the above branching model.

I've used above branching model and tools for several years now and I can't imagine doing something else. It really cleared things up for me when I found it.

from foreach.

Also, lately I've made develop my default branch on GitHub so that people can see what's new and when they fork and create PRs that's the branch they work on.

from foreach.

Yeah, it's just a bit complicated here because master isn't really a master; it's another staging branch that contains some of the work done to interop with future. The rest of the work is in richcala/foreachFutureTake3.

I think the reason for this structure is because master corresponds to the version of foreach loaded on the Azure DSVM image, but that's actually pretty old now.

from foreach.

I've now done something like what you suggested and made the new "staging" branch the default.

from foreach.

Another thing you could do is git tag 1.4.8 and git push --tags to tag commits corresponding to the different CRAN releases. (That way you can also install_github("org/repos@version"))

from foreach.

I've renamed master to mro/1.5.2 to reflect what it actually is. I'm not too worried about tracking releases, since they're always available from CRAN itself.

from foreach.

You want to have a master branch, which I suggest should be the latest release (see above). Some tools expect a master branch, e.g. remotes:: install_github().

Not critical, but tagging CRAN releases help devs/users when troubleshooting among other things, e.g. makes it easy to git diff what changed etc. The git flow tool does this automatically.

Tags can be kept for ever. Most branches tend to come and go.

from foreach.