Use tags for versions

[OliverJAsh]

I think the npm module should download the latest version via a tag, instead of just cloning the HEAD of this repository. At the moment it's not really safe for anyone to just clone this repository because there's changes all of the time and very little has been decided. Thoughts?

[jackfranklin]

Agreed, but can you post this in the npm repo please as it's an issue of that :)

[OliverJAsh]

I was thinking that, but then this is the repository we need to implement the tags onto. So it's a decision that needs to be made with regards to this repository!

[jackfranklin]

Ahh in which case we have two issues.

• npm module clones directly from head (post that issue into the npm module repo)
• set up a latest tag or similar on Git that the npm module can grab (which can be this issue).

Reopening to discuss the later.

I'm not too up on my git tags, is it possible to reassign a tag?

[OliverJAsh]

  -f, --force
      Replace an existing tag with the given name (instead of failing)

[OliverJAsh]

Not sure if we should use a latest tag, or just produce new tags for every version and update the npm module.

[jackfranklin]

Or, as @mheap just pointed out on Twitter, we use the master branch as the latest stable build, and have a develop branch. Then we don't need a latest tag.

I think we should use a latest tag rather than redefining the npm module, else people will have to update the npm module, which is ridiculous - if we use a latest tag that is.

I'm all for having master & develop branches.

[OliverJAsh]

Agreed.

Do we want tags for every version, just in case we ever need to quickly checkout an old version? Thinking long term here.

[jackfranklin]

Yeah, we do (I've been doing it so far).

We need to think a bit about how we do this process. IMO:

work entirely on the develop branch when we are ready to release a new build we have to:

• git checkout master && git pull master && git checkout develop && git merge master && git checkout master && git merge develop
• update changelog, package.json with new version and changes
• git commit -am "Updating to Version X.Y.Z" to commit the package.json and README/changelog edits
• git tag vX.Y.Z
• git push origin master && git push --tags

[OliverJAsh]

This looks interesting: https://github.com/nvie/gitflow

[jackfranklin]

Yeah I've seen that before. I wonder if it might just be a bit overkill though...two branches should do us fine...what does everyone else think?

[mheap]

+1 for Git Flow. Develop can change day to day, but should work 100% of the time. Feature branches are the way to go - it encourages pull requests internally too.

[OliverJAsh]

How do "internal pull requests" work then? Can we do those without Git Flow, if we are only operating on two branches: master and develop? On 22 Jan 2013, at 15:52, Michael Heap notifications@github.com wrote:

+1 for Git Flow. Develop can change day to day, but should work 100% of the time. Feature branches are the way to go - it encourages pull requests internally too.

— Reply to this email directly or view it on GitHub.

[mheap]

You can, but it doesn't really work with 2 branches.

If you use feature branches, you set them up to be pulled into develop, then merge into master when you have a release.

[jackfranklin]

Interesting, didn't think of it that way. Happy to go with git-flow if that's the general opinion :)

[OliverJAsh]

I've just released v0.5.0 using Git Flow, and this repository now contains a develop branch, so I would advise everyone works with Git Flow from that branch.

[OliverJAsh]

P.S. be sure to enter v when git flow init asks you for a "version tag prefix". That's what @jackfranklin’s gone with so we should keep with it.

[jackfranklin]

@OliverJAsh would you be able to document the settings you used for getting git flow set up, perhaps in the Wiki, and a quick start guide to using Git Flow? (or link to some).

Going to close this now :)

[OliverJAsh]

I would like to try this workflow as I've never tried it before, and it sounds appropriate! On 22 Jan 2013, at 17:56, Michael Heap notifications@github.com wrote:

You can, but it doesn't really work with 2 branches.

If you use feature branches, you set them up to be pulled into develop, then merge into master when you have a release.

— Reply to this email directly or view it on GitHub.

[jackfranklin]

I just tried it and I love it already! Lets stick with this.