How to use branches properly about vesseljs HOT 12 CLOSED

Ok, I'm using a fork now, as you can see with PR #35.

from vesseljs.

Ok, if this should make the version control simpler, it's fine for me. I already verified that all modifications I committed to dev made it to master.

from vesseljs.

I am not sure, really. But I think we can give it a try.

from vesseljs.

Now I have removed the dev branch, and completed a commit and PR with my own fork. It works.

from vesseljs.

Note also that forking allows you to test your own version of the GitHub pages. Just go to project settings, and find the GitHub pages section. Here is an example from my fork (master is up to date right now, but I could have another version running here): https://eliashasle.github.io/vesseljs/examples/Ship3D_GA.html

Update: This can also be achieved by using a CDN like githack, even on single commit level.

from vesseljs.

Now it looks like one can use "update from shiplab/master" in github desktop, but maybe it is necessary to click "sync" first. Hm.

from vesseljs.

By the way, let's make this a contributing guideline and write it down somewhere on the repo or wiki. I'll do that.

from vesseljs.

from vesseljs.

@hmgaspar @icarofonseca @DiogoKramel @ferrari212

Now (again) I recommend following the example of three.js. They have a master branch that is updated every second week or so, representing a release (monthly releases may perhaps be more realistic for vessel.js), and a dev branch that is updated much more frequently. Only well-discussed and well-tested changes make it to master. In practice, this means greater changes are rarely introduced even to dev in the last days before a new master release, because dev must mature enough to be ready for master. Pull requests are based on dev, and can stay open for weeks and months (sometimes years, but I do not recommend that...), depending on how complex or controversial they are.

from vesseljs.

Ship3D and Ship3D_v2 should be merged together. Likewise with ShipState and ShipState_new. Having them separate is just a mess. However, merging them will also require updating, or removing, a few old examples. One option will be to make a small "Legacy" release to support, and then move faster forward with merging the competing classes, effectuating #107, moving to classes and modules etc.

from vesseljs.

@hmgaspar I now added a dev branch again, and I request that you make it the default branch (I don't think I have the privileges). Then we touch master only when we are ready for a new release.

from vesseljs.

Ok, good idea.

from vesseljs.