0.3 vs. Redux
Ryan Tomayko
the non controversial bug fix type patches that have been floating around
applied to the "next" branch. I'd like to propose a few things:
- My master is the "next" branch plus some other stability and cleanup type
changes. I propose shipping this as 0.3 and letting me maintain a series of
0.3.x point releases that's focused on bug fixes and minor changes against the
current codebase. The redux branch could then be shipped as 0.4 once it
reaches feature parity with 0.3 and stables up a bit.
- I've ripped out Echoe and added a sinatra.gemspec file. This makes it
possible to have github build gems (I can 'gem install rtomayko-sinatra' from
my master now). If you give me access to the sinatra project on rubyforge, I'd
be more than happy to take on publishing gems for both the 0.3 series and the
redux/0.4 series when it's ready.
- Lighthouse is a mess. Give me admin privileges and I'll take on shepherding
bugs fixed/slated for 0.3 and create a separate milestone for 0.4 where we can
focus on the redux branch. I've tagged everything that made it onto my master
as "fixed" but I can't do anything else with my current privileges.
- http://sinatrarb.com - WTF?! At least redirect to the github README. I know
it's down due to wiki attacks or whatever but the wiki has been less than
useful anyway. Personally, I thought it was better when it was the README with
some light styling. The wiki has never been nearly as useful as the old
homepage and it looks really horrible to boot.
I'm still a bit stretched for time at the moment but I can dedicate at least
enough to manage a routine release schedule and help make sure the patches
coming in through lighthouse/github find their way into a gem. The redux
branch is starting to look pretty damn interesting but some of this managerial
crap needs shored up or we're not going to have the basic processes in place
to ever release it.
Ryan
Ryan Tomayko
to run the next couple of releases...
Ryan Tomayko wrote:
> - My master is the "next" branch plus some other stability and cleanup type
> changes. I propose shipping this as 0.3 and letting me maintain a series of
> 0.3.x point releases that's focused on bug fixes and minor changes against the
> current codebase. The redux branch could then be shipped as 0.4 once it
> reaches feature parity with 0.3 and stables up a bit.
So, moving forward, my master (http://github.com/rtomayko/sinatra/tree/master)
will be the integration point for future 0.3.x releases. Blake's "redux"
branch is the integration point for 0.4. The 0.3.x series will be the official
stable release until the redux branch takes over. Patches and pull requests
should be directed to me for all 0.3.x related changes.
Since the 0.3 and redux branches have no common base, it's important that
patches/clones are against the right branch. Here's some guidelines for patching:
Stuff that should be directed at 0.3.x (based on rtomayko/master):
* Stability, performance, and bug fixes for current 0.3.x release
* Tests
* Documentation additions / corrections
Stuff that should be directed at 0.4.x (based on bmizerany/redux):
* Experimental features
* Feature ports from 0.3.x. (talk w/ blake before porting stuff - not
all current features are guaranteed to make it into 0.4)
* Fixes, documentation, and tests specific to the redux branch.
> - Lighthouse is a mess.
We've cleaned up Lighthouse a bit and split open issues into two separate
milestones: 0.3.0 and 0.4. We're not going to create separate milestones for
each point release to keep the number of buckets down.
> - http://sinatrarb.com - WTF?!
bmizerany and sr have been working on getting the Sinatra wiki up and running
on heroku. It's still a private work area atm, but I got a quick peek and it
looks a million times better than the old wiki setup. Heroku's going to open
up some interesting possibilities for team editing and other cool stuff as well.
Thanks,
Ryan