Hyperapp: app(...) does not return emit

[amatho]

Correct me if I'm wrong, but it seems like a call to app doesn't return the emit function. The docs describing this behaviour is here

[lukejacksonn]

Good spot! AFAIK.. the docs have been updated to reflect changes to the code that have been merged but have not yet been released.

The app function should return emit as described in the docs, once 1.0.0 is released (unless there is a pre-release). See here for the related commit https://github.com/hyperapp/hyperapp/pull/280/files#diff-bd9c9dcd314f2d7df52935b3a6a4d504L26

Sorry 🙏

[amatho]

Ah, that makes sense. Thanks for the quick clarification 👍

[Swizz]

Dont we need a support branch (or tag) of the current released version to keep the doc synced ?

[lukejacksonn]

We should really. IMO master branch should really represent the current release and we should be merging 1.0.0 changes into a release branch that we can cut and merge all at once when the time is right.. what are your thoughts on this @jbucaran?

[zaceno]

@lukejacksonn If master is just the latest official release, then we'd need a "dev" branch into which to merge PR's. And that would probably confuse anyone making a PR (I can imagine a lot of PRs mistakenly made toward master). I think the way we're branching & tagging releases today, is kind of how Github is designed to be used anyway.

[Swizz]

In github we can set another default branch than master

Default branch

The default branch is considered the “base” branch in your repository, against which all pull requests and code commits are automatically made, unless you specify a different branch.

[zaceno]

@Swizz Cool didn't know that

[jorgebucaran]

@lukejacksonn What are your thoughts on this @jbucaran?

That I agree, but it would make my work more difficult at this stage. I always seek self-improvement, so I am happy to hear about other people's workflows too and if a nice and easy to understand process is described here I might even adopt it.

[davidmh]

We should really. IMO master branch should really represent the current release and we should be merging 1.0.0
then we'd need a "dev" branch into which to merge PR's.

Git-flow is a great branching model that does exactly that and automates the convention.

This is my go-to screencast to show as an introduction to both the concept and the git extension: https://vimeo.com/37408017

[jorgebucaran]

Thanks @davidmh! Will watch it tomorrow. 🤔

[lukejacksonn]

@jbucaran no worries.. just curious!

if a nice and easy to understand process is described here I might even adopt it

I'll try get one of these down on paper 🗒

[lukejacksonn]

@amatho closing this issue now as it has been answered. Will reference it when the next person notices that app doesn't return emit (yet) 😅