Merge develop branch onto master

[jstclair]

Is there any reason why develop is so far ahead?

[gnab]

No reason, think we even used the develop version at Statkraft in the end, so master may be brought up to speed with develop.

[jstclair]

Yep we were, so it was a bit confusing. Probably should have done that first.

I think it's probably best just to do dev on specific feature branches and then send internal pull requests rather than maintaining a long running dev branch - what do you think?

On 2. des. 2014, at 23.22, Ole Petter Bang notifications@github.com wrote:

No reason, think we're even used the develop version at Statkraft in the end, so master may be brought up to speed with develop.

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

[gnab]

For remark I've set develop as the default branch, which then becomes the branch people create pull requests for, which I can take into the develop branch without affecting master, which is where I want to do stuff only when I release a new version, taking in stuff from develop in an "atomic" fashion.

I'm not sure if that scheme is needed for editableCell, but at least that's kind of why I have it like it is.

[jstclair]

Ah ok. I can see the logic!

But! I also think that sounds a bit overkill with GH Releases being tag (rather than branch) based.

Is the idea for people to send pull requests against master?

On 3. des. 2014, at 08.46, Ole Petter Bang notifications@github.com wrote:

For remark I've set develop as the default branch, which then becomes the branch people create pull requests for, which I can take into the develop branch without affecting master, which is where I want to do stuff only when I release a new version, taking in stuff from develop in an "atomic" fashion.

I'm not sure if that scheme is needed for editableCell, but at least that's kind of why I have it like it is.

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

[gnab]

The develop branch is a lot like a long-lived version of the integration branch you introduced at Statkraft.

The default is that pulls go against master, but like I said, I think using a integration / develop branch to prep stuff going into master pretty nice and tidy.

I'm simply more used to / comfortable with branches than tags, I guess. But maybe we could try using master as the default branch for editableCell and remove the develop branch, and do everything else in separate branches / pull requests, and handle releases entirely using tags. It would be nice to try out.

[jstclair]

Whatever you'd like 👍 I'm just planning on wrapping up some of the bugs first, then merging to master so we can publish a proper set of packages (for Bower & Nuget, it's a bit awkward pointing at develop). After that, either way works for me.

[gnab]

Master should always be the latest release, the way I have it now. So in any case, master is way back and should really be moved forward to match up with develop.

Btw, isn't Bower using releases and not branches?

I think it's nice to try something new for a change, so focusing more on tags and less on branches to deal with releases is what I'm voting for :)

[jstclair]

OK sounds good.

Bower is a bit strange due to it’s being less of a package management system and more a protocol - at least according to:

http://bower.io/docs/creating-packages/#register http://bower.io/docs/creating-packages/#register

it’s possible to point to various things, but the ‘default’ (i.e., master) is probably easiest…

I’ve merged prototype-stuff onto develop. I’ll look through the issues and unless something stands out, merge dev onto master.

Oh, do you have a pointer for how you built the docs? I’ve installed docco, but the output is completely different from the local docs. Was that generated before your broke it up into separate files? Now, I can run it like:

docco src/*/.js -out docs

But that generates a doc file per item.

Instead, if I do:

dock out/editableCell.js -out docs

Then I get all the comments from EventEmitter and such…

JOY

/j

On 03 Dec 2014, at 09:48, Ole Petter Bang notifications@github.com wrote:

Master should always be the latest release, the way I have it now. So in any case, master is way back and should really be moved forward to match up with develop.

Btw, isn't Bower using releases and not branches?

I think it's nice to try something new for a change, so focusing more on tags and less on branches to deal with releases is what I'm voting for :)

—
Reply to this email directly or view it on GitHub #18 (comment).