Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Nick McCurdy
@nickmccurdy
Nice! I'll check it out, need any help troubleshooting?
Douglas Wade
@doug-wade
I pushed a WIP branch that is pretty close
The tests aren't passing, though, so any help with that is well appreciated
I'm gonna take a breather and knock out some docs tickets before diving back in, probably Thursday evening PDT
Nick McCurdy
@nickmccurdy
Awesome, I'll take a look at your PR tonight or tomorrow. Might push to it if I can figure out how to fix test failures
Douglas Wade
@doug-wade
Thanks! Much appreciated
Nicolás Fantone
@nfantone
Hi all!
just joined the channel
left some comments here and there in the repo
gonna work on koajs/koala#50
and send a PR soon
:)
@/all I'd like to create a develop branch - would you be ok with that?
also, we should make it the default branch on the repo so PRs default to it, instead of master
Douglas Wade
@doug-wade
@nfantone what problem are we trying to solve by maintaining two branches?
I've never maintained a develop branch, and I don't know the benefits, I'm only familiar with the costs (cherry-picking, backporting, rebasing &c)
Nick McCurdy
@nickmccurdy
@nfantone Hello! :)
I'm hyped about your eslint standard PR, reviewing it now
I have maintained a develop branch in some projects before
Personally I don't see much benefit for this project because at this point it's still in alpha with an unstable API
If releases get too unstable or difficult to plan after we have an initial stable release for Koa 2 I would like to try a develop branch then
Also I prefer the base branch to always be more stable than a development branch (if any), otherwise having different documentation for in development features could confuse users
Nicolás Fantone
@nfantone
hi, guys :)
@/all agree with the "alpha software" comment there - but keeping a develop branch has its benefits and doesn't really carry any of the costs @doug-wade mentioned (if done properly)
it'd work like this: develop essentially becomes what master is now
and master holds the latest released state of the project
Nicolás Fantone
@nfantone
we backmerge things to master on releases only
which should be done automatically
and since no one is pushing to master there should be no conflicts, and no cherry-picking, backporting, rebasing needed

Also I prefer the base branch to always be more stable than a development branch (if any)

The "base" branch being the one you develop on? If not, then master becomes your "base". develop is always ahead of master

there's this famous post by nvie describing gitflow here: http://nvie.com/posts/a-successful-git-branching-model/#the-main-branches
Nicolás Fantone
@nfantone
(sorry if I'm being patronizing here - maybe you knew all of this already and I'm being a drag)
Nicolás Fantone
@nfantone
@nickmccurdy you around?
Nick McCurdy
@nickmccurdy
I see, I'm aware of this approach
Sorry by base branch I meant the default branch displayed on GitHub
IMO a project doesn't gain much by having a separate development branch if the default branch is development
If the default branch is development it's essentially renaming master to development, still potentially keeping breaking documentation changes in the default branch, and providing a ref to the latest release that's hidden behind a non-default branch when the latest release can be viewed on GitHub instead
Nick McCurdy
@nickmccurdy
I think the git flow model exceeds more for things like apps where the master branch is likely to be deployed constantly by CD
For a library, we have npm releases for that, and our GitHub tags should mirror that anyway
In other words it's unlikely that master is being installed directly so IMO it's okay to use it as the "development" branch conceptually, but leave the name as master to make it obvious that it's the default branch
Honestly I'm fine either way, as long as we agree to a convention and stick to it
Note that Koa itself is doing something similar to what we're doing now and doesn't have a development branch
Douglas Wade
@doug-wade
I'd prefer not to maintain a develop branch. It sounds like the problem we're trying to fix is clients not understanding that master is ahead of the lastest release, but I don't see a lot of questions around that in Gitter, so I'm inclined to postpone making the change until what we're trying to solve is affecting us.
I also suspect we'd have the problem of contributors branching off master rather than develop accidentally more often, though I don't have any data to back that up.
I'm with @nickmccurdy that we'd see a lot more benefit if we had CD. It's likely possible for us to set up (via travis with tags). If we get that set up, I'd also be much more persuaded.
For now, let's stick with master-based development
Nick McCurdy
@nickmccurdy
Totally agree, especially with the CI bit
Development branches can be a good idea but IMO it's not a good fit for most projects
But it's definitely something we can think about for the future if we have those issues
Bhaskar Melkani
@bhaskarmelkani
Hi guys,
I made a minimal boilerplate on topof koajs. Will love your feedback on it.
https://github.com/bhaskarmelkani/coko