Now Reel 0.6 is out, any chance of cutting a 0.5 Angelo release?

[grizzlydev]

looks like this is work in progress - anything we can do to assist?

@kenichi Great work here BTW, love this framework

[kenichi]

@grizzlydev thanks! looking at 0.6, some PRs weren't included... #189 and #191? skipping rack being left in as a dep, the forward to ping is used by angelo: not hard to change, but i'm wondering: @tarcieri can you shed any light on that?

[digitalextremist]

Are those two the only ones blocking 0.5 of angelo?

[kenichi]

@digitalextremist well before pushing a gem version, i went to test things and they were broken. angelo was tracking the 0.6.0-milestone branch of reel, which doesn't seem to be the branch used for 0.6 release. angelo doesn't actually care about rack or not, that's a personal preference; but it does care about where websocket#ping is - like i said, not a hard change, but had me wondering what happened.

[digitalextremist]

I will recheck the release and check this. If you have specific unmerged code/branches please point them out.

[kenichi]

@digitalextremist well the commits from those PRs specifically :smile:

also, i kept saying "not a hard change", but it seems there's actually no exposed way of pinging the client over a websocket in reel 0.6. i have some new branches from the 0-6-stable branch: no_rack_again and ping. the rack one includes the ping one, but i kept a separate branch in case there was reason to keep rack that i'm unaware of.

let me know if you want PRs for one of those. since angelo attempts to "make websockets easy" and pinging the client to keep them open is part of that, i don't want to cut a new gem based on current reel 0.6...

[kenichi]

@grizzlydev you can check out the new reel_0.6 branch for a sorta working angelo. be aware it only works against my forked branches of reel - ping or no_rack_again (see https://github.com/kenichi/angelo/blob/reel_0.6/Gemfile#L3)

[tarcieri]

@kenichi let me shed some light on the branching scheme that Celluloid projects use (I can't speak to @digitalextremist's branches, this is just how every other branch in every other project works):

• master*: the next major upcoming release. Most PRs should be made against master
• x-stable: for bugfix releases against the last minor release. Generally commits to this branch should get cherry-picked from master

tl;dr: make PRs against master

I'm not sure what all of the branches @digitalextremist made were about, but using an excessive number of branches causes this very sort of confusion, and were also inconsistent with the existing branching model.

Anyway, please use ^^^ branching model in the future

[kenichi]

@tarcieri k, thanks. PRed master.

[digitalextremist]

( There was an unusual situation leading up to 0.6.0, like the situation leading up to 0.17.0 of celluloid, which lead to using the 0.6.0-milestone branch and a few others, but usually the master/x-stable strategy is what's used )

[kenichi]

currently waiting on 0.6.1 - 0.6.0 is a broken release: can't ping websocket clients

https://github.com/celluloid/reel/issues/222

[tarcieri]

@kenichi I will do a release tomorrow

[tarcieri]

0.6.1 released

[kenichi]

0.5.0 released