search

hiscom / hispid

HISPID Terms
6 stars 1 forks source link

Document in the wiki the process and conventions that are to be used to maintain the standard #39

Open AaronWilton opened 9 years ago

AaronWilton commented 9 years ago

need to document conventions for: branching milestones

AaronWilton commented 9 years ago

For standard development work that we are doing I think we are more after the BRANCH option 1) It keeps the repository together so we can work collaboratively on it… (cf FORK which makes your own distinct, personal copy) 2) If I am not mistaken (and there is a good chance that I am!) FORK is a github concept not a pure GIT concept -> implications for tools? Transfer to other repos? My vote 1) is that we only use Branch 2) We have a single development branch that is the Branch that will be VOTED on for inclusion into the MASTER 3) We can have other feature branches that we work on that will be merged back into the development branch, then if accepted into the MASTER We should transfer this discussion to https://github.com/hiscom/hispid/issues/39 I will copy this email to that issue Cheers A

From: Niels Klazenga [mailto:Niels.Klazenga@rbg.vic.gov.au] Sent: Tuesday, 17 March 2015 5:39 p.m. To: Ben Richardson; Aaron Wilton Cc: anne.fuchs@environment.gov.au; eleanor.crichton@sa.gov.au Subject: RE: HISPID Review telephone hook-up

And that I know how to do, as that is how I edited the AVH Advanced Search page. Also, anyone can do that, not just us, and we still get to decide what goes in and what not. I think both viable alternatives.

"Richardson, Ben" Ben.Richardson@DPaW.wa.gov.au 17/03/2015 3:32 PM >>> Aaron,

Were you suggesting we each work in our own branch? Or was it that you thought we could share a development branch?

GitHub has the concept of forking, which goes even further, copying the entire tree into my account, perhaps this is even better?

Cheers, Ben

nielsklazenga commented 8 years ago

I think whether to fork or not to fork is not the question. People who are not owners who do want to make changes have to fork anyway and have to do a pull request. Owners can decide for themselves whether they want to push directly into the hiscom/hispid repository, or want to push to a fork they created in their own account and send a pull request, which they can then merge themselves (seems an unnecessary detour to me)..

The question is what we want to do with changes that are pushed or pulled into the hiscom/hispid repository, whether they go straight into the master, or whether they go first into a branch, which can later be merged into master. Aaron wants the latter and I think (now) that makes sense, as that means the master will never be in between two "versions" and will always have the current version.

AaronWilton commented 8 years ago

Yes - that is a good summary Niels.
Using a Master branch and a new version branch would also allow us to make minor corrections to the master - so called hot fixes while we are working on the next version - in this cases those hot fixes would be minor/trivial edits I guess (e.g,. typo's in note or similar)