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?
Whatever we decide, it should be for 0.7, whether that means pushing the release out a little longer or not. Lots of people were reluctant to embrace the Developer Previews because they're viewed as too buggy and for (duh) developers only, but no one's yet expressed any interest in a beta release, which would undoubtably draw a larger audience. I'm still of the opinion that a little longer will *not* hurt, but releasing a beta or two could definitely help if it's something you're concerned about. 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). On Feb 2, 2011, at 10:54 PM, Owen Winkler wrote: > On 2/2/2011 9:49 PM, Chris Meller wrote: >> >> I don't like the idea of adding a new plugin that provides a block to >> core just so we can have a plugin that provides a block, that's never >> been the Habari way. If the overwhelming majority of users aren't >> going to use it it's always been our policy that it should be left in >> -extras and I don't see any of the suggested options so far (aside >> from dashboard modules) being used by the vast majority of our >> install base. >> >> That said, if we wanted to provide a plugin that really used blocks >> well (ie: got block wrappers and scopes right, used the block CSS >> classes assigned, etc.) and offered some common requests (monthly >> archives, recent posts, recent comments) I wouldn't be opposed to >> that. > > I think its a good idea to ultimately switch the dashboard over to using > blocks instead of modules. However, this would once again throw a wrench > into release. > > At the same time, I think that core themes need to be augmented to make > better use of blocks if we're going to bother including block plugins in core > too. We should examine what features core themes provide currently that > could be replaced with blocks, and then change the themes to use areas and > include blocks to replace that functionality. > > My question at this point is, what we should do now?: > > 1) Release as-is without a core block plugin and immediately revisit this > whole issue for a very fast 0.8 release. > > 2) Include a simple block plugin (literally "simpleblock", or alternatively > "commonblocks" would be my suggestions) for 0.7, and then revisit the core > themes for a fast 0.8 release. > > 3) Review core themes now, replace all their block-like functionality with > areas and a new core block plugin, which may push the 0.7 release by a month > or so. > > 4) Update core themes and produce a core block plugin as in 3, and also > replace the admin dashboard with a block-enabled theme page, which will > postpone 0.7 for an indeterminate amount of time. > > My personal preference on this issue ranges from 1 through 3, with a keener > interest in option 1 corresponding to our ability to guarantee a fast release > date for 0.8 with just the additional features from option 4. > > All that said, option 2 intuitively feels like a nice compromise for > including sample block functionality in core without delaying it too much, > which is why I think this suggestion is on the table. > > I think we're way beyond the point of saying "a little longer after so long > already won't hurt". It *will* hurt to delay, and at this point I'd rather > roll out a better 0.8 in March and potentially have to rip out a poor choice > for 0.7's core block plugin than delay the 0.7 release to April to add core > dashboard blocks. > > If we wanted to, we could add a single -extras block plugin to 0.7 now, tag > it off in makaanga, and start work on the changes from option 4 for release > in 0.8. Fix bugs in branch and release the damn 0.7 already. > > 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 -- 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
