On 2/3/2011 12:16 AM, Chris Meller wrote:
I'm not in favor of any of the options that involve "a very fast 0.8 release". That screws up our roadmap (no big deal) and puts a lot of extra pressure on us to throw together in a hurry something we should have probably done better the first time. If we can't throw it together in a reasonable amount of time for 0.7, why would we think we could if we released 0.7 and planned to do a 0.8 in the same amount of time?
That's exactly the reason to do it in 0.8 instead, so that we can take more time in 0.8 to concentrate on those issues. The idea also being that we could use this as a trial run to get the quicker, more regular releases everyone's been wishing we had. That we haven't had a feature-updating release since April 2009 is somewhat damaging.
We definitely should at least review the state of the core themes currently. Their implementation could certainly be improved in a 0.7.1 bugfix, but if we throw blocks out there and ask people to start building on them it'd be nice if we didn't break everything they just did when we "fix them for real" in 0.7.1 (or 0.8).
This is one of the options I presented, and I'm not against it. As I said, I would be more in favor of my option 1 if we could commit to a very fast follow-up of 0.8 with just the features we didn't add. If we're not going to do that, then that's not the answer, and option 3 makes more sense. How long it delays release to make these changes is debatable -- I was hoping for February of 0.7.
Also, I think that blocks are API-ready. We're not asking people to build on something that they'll have to change completely in the next version. Maybe I'm wrong about that if people haven't been testing the block functionality in their themes the DP's. There are at least some UI glitches that I would hope to clean up during the freeze. The point I'm making here is that I think if we did a follow-up 0.7.1 or 0.8 release, it shouldn't break what we've asked them to build, but sure, it would be nice to get confirmation of that by banging areas into the core themes (and ditching K2 and adding a HiEngine theme to core).
Also note that blocks aren't specified explicitly on the roadmap, but would presumably fall under 0.8 (themes and multisite) rather than 0.7 (taxonomy and content types). (http://trac.habariproject.org/habari/roadmap) My opinion of the roadmap is generally low simply because it's half-baked thoughts we've tossed around on IRC and have ended up being put into Trac seemingly just so the page exists. If we switched to the frequent regular release schedule that everyone has been espousing, this roadmap wouldn't make any sense.
Owen -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
