Add path.posix, path.windows

[jjl]

My original patches to lumo contained these namespaces which appear to have gotten lost. Could we get them back?

[jjl]

Also, my tests!

[yogthos]

Ah right, I'll take a look at adding those in. 👍

[jjl]

Incidentally, since I'm likely to need a bunch more and the macchiato org seems to be a good place to keep these things - what other node libraries are you interested in having wrapped?

[yogthos]

I could add you to the org if you'd like. Anything you think might be useful for web apps. @ricardojmendez is working on wrapping database drivers, but we're going to need a migrations library as well.

[jjl]

That would be good. As I find I need things, I could just add them.

Down the line, we're going to need npm stuff. I was messing around with the npm-cljsjs project and made a bunch of changes (it needed npm v2 amonst other things), but it's not yet usable to package npm.

[yogthos]

I found lein-npm works pretty well, it effectively treats npm dependencies as regular leiningen dependencies. Only bug I found is in generating package.json, have to take a look at some point. It prints it to stdout instead of a file.

[yogthos]

You might also want to talk with @ricardojmendez about gitflow if you're not using it, looks like we'll be going with it

[ricardojmendez]

Somebody summoned the Repo Tyrant?

@jjl: Yup, we're going to be using git-flow for libraries. Plan is to keep a develop branch with the SNAPSHOT version and to do period releases to master.

Also, please note your changes on a changelog. Not all repositories have one yet. If you run into one where that's the case, please start one.

[jjl]

The rationale for the develop branch does not (IMO) make sense for clojure (where our build tools want jars anyway). I'd prefer that in repositories where tests are up to scratch we didn't bother with the extra staging in develop before master.

[ricardojmendez]

@jjl I don't see the relation with tests or lack thereof. It's about keeping changes that haven't gone live in a single place, and being able to trivially do hot-fixes to released libraries without throwing in other features we hadn't planned to release yet.

You can read more about my own rationale here.

[jjl]

I think unfinished features belong in feature branches and that when you take those out and everything has tests, you find you don't need a develop branch.

[ricardojmendez]

It seems we are looking at different reasons behind a develop branch, since tests keep coming up.

I don't think it's there for "unstable", "unfinished" or "untested" code. To me, it's there just for code that hasn't been released into the wider world yet, and for which the implementation may end up changing before we do so based on feedback or internal use.

In such a case I'd merge in the feature branch once the implementation is finished, but would retain it on develop while I use the SNAPSHOT version myself, since there are things I may not have considered while implementing it. I've found that this separation helps for libraries in the past.

Furthermore, I see the value of keeping everything on master when there's continuous delivery involved, but given that is usually not the case for libraries, I perceive it as losing the organization value while not really adding much.

Having said that, that's by and large @yogthos' call in this case, however, or in the more general case that of whomever starts a specific library.

[jjl]

Okay, I think I understand your reasoning, but I still disagree :)

We use what you call 'github flow' for the libraries at @irresponsible and it seems to work pretty well.

[yogthos]

I think it'll make most sense to follow the workflow of whoever is going to be the primary maintainer for the repo. @jjl if you're ok with taking the lead on this one, then let's go with the github flow. :)

[jjl]

Okay, I'll get cracking on this once I've finished off my client work :)