I like the pragmatic work-flow of sticking to one master branch. This makes it easy to collaborate. Separate temporary branches can be made for pull-request and feature developments that are merged into master. Then, use tags to specify when versions are released.
Then, later on when you do want to back-port fixes to previous releases you can start creating separate branches for your minor versions (1.1.x), which you will only apply the fixes and patches to.
The branch model you described is most useful when you back-port fixes to previous releases. I.e. supporting older versions. I assume you don’t want that just yet as you would still be on version 0, waiting for the beta and final releases of the SAFE Network.
So does this mean when you push origin you are generally pushing to master?
I’m still feeling my way around this. My thought was to try not to mess with master until there’s something ready to go through a release process. I think I picked that up from the remoteStorage.js guys, but could be mistaken, I didn’t understand git much at all then (not much more now!).
If you’re collaborating on GitHub a lot, probably not. You’re pushing to your pull request branches. But yes, if you’re just working on small tweaks and meta-commits then you could.
I totally get that, I thought that was the only ‘right way’ for a while. There is no right or wrong, but what I propose is definitely less complex.
I just noticed it’s also the flow that GitHub recommends. Working with pull requests generally makes a ‘development’ branch unnecessary. It also seems to become more popular to work without a development branch. Anyhow, tailor it to your specific processes and structure. I think the GitHub flow is simple and works great for me and other larger projects.
Bit confused here as development is me working on a branch. I don’t expect others to work on that branch, and while building it from scrattch alone so far, there isn’t much point in creating a different branch for short pieces of work, although I have done that a couple of times, for learning mainly.
So what is it in the process I’ve described in the OP that you would change? When people join in [cough], I can see us each working on a separate branch and submitting PRs to a joint branch or master. So is the difference just about whether the PRs go to master or a branch which I guess would be development but I would not longer work on directly?
Thanks for your input BTW, very helpful to be able to discuss this with you.
I guess what I’m suggesting is that there is no specific development branch, only ‘feature’ branches (branching of master for writing a specific feature) that merge into master (with GitHub using pull requests).
In OP you’re describing a specific RC branch, which is something I would not do. Just use the pull requests to test if the code can be merged with master and passes the tests. Then, master will only contain code that passes all tests. Tagging/releasing from master is then similar to your OP idea.
I am a bit untrusting of this, so that’s why I put the extra release branch in. Simple is good though, so I’ll probably live dangerously and follow your advice! Thanks again.
I don’t think you have to be if you integrate testing into GitHub. It shouldn’t be dangerous at all! You should actually feel more confident if you’re testing and releasing all the time instead of being afraid of the holy master branch.
Well I haven’t done this and don’t have the time atm. I have one bash script that exercises the file system is all. As that requires SAFE mock or live, I expect that’s not easy to integrate with github, if it is possible at all.
I’d like a proper test suite at some point, but that’s all I have for now, nothing directly on my functions. So it will be a lot of work to get to your ‘trust github’ state. I can only dream
I don’t think the SAFE APIs should be any problem. (@maidsafe also uses tests via GitHub/Travis at maidsafe/safe_app_nodejs.) I am not sure about integrating FUSE though as that requires quite a specific environment to work on I assume (filesystem/mounting).
I agree with @bzee’s suggestion of working with PRs for feature branches etc. We use this for our repos and it keeps things clean/manageable.
Github has a great interface for reviewing / approving / commenting in this workflow too. Which can certainly be handy for open source stuff.
I’d heartily recommend getting travis set up (they even offer windows now [in beta], which we’re trying out as Appveyor has proved a PITA at time). I’ll hopefully get to dig in a bit next week, so maybe I’ll fire a PR with a travis.yml) (then all you’d have to di is activate travis for your github profile/repo, which is pretty painless)
It’s a great buffer for PRs as you can specify things to run, and if tests dont pass, it’s obvious for those submitting the PR what they need to do (format the code in a specific manner… add tests for their code etc).
Any help gratefully received. It feels like a big task though, to get the environment set up and work out a way of authing with SAFE, before running a bash script that accesses ~/SAFE
How would that work with mock?
Is it even possible with a live network? Required for some tests, and also as a final test. It would also use too many PUTs to run the whole suite, so I would prolly just do the live only tests on that.
Thanks for the input. I will certainly go the way you and Benno suggest
For mock that could mayyybe be done by storing/populating a pre authed mock vault, and keeping the URI, such that loginFromUri need only be called. I think that’d work.
But you’re right, we definitely do need a headless way of authing.
Is it even possible with a live network?
No, I don’t think so. (At least not at this stage with forum account trust levels and ip registration etc).
But even aside from testing the network functionality, some tests should be viable to check sub sections of the code (I imagine). So even if full network integration isn’t possible, there’ll hopefully be some value to be gained from CI.
Yes, there’s plenty of scope for this and it would be great to have. Just… you know, time! Esp. as I haven’t done this before, but even if was just writing the tests its a lot of work to module test this API. There are so many ways to mess with a FS, and it is more than that. God it is a lot of code! I must do a line count.
Anyway, thanks for the input. Points noted for future reference. Cheers!
and follow your advice! Thanks again.
