On dealing with legacy issues in the future
Michael Heilemann
Take a look at Windows and OS X for instance. Microsoft does everything in their power to make Windows backwards compatible, whereas Apple is just the opposite. I personally belong in the Apple camp, and that's the way I've always run K2, but I'd like to hear opinions on this for Habari.
I'm asking because one of the things WordPress really has a problem with is the lack of 'fuck it, let's do fix this so it's done right'. I mean look at Kubrick for frak's sake, it's filled with lots of weirdness that should've been fixed a looong time ago.
--
Aloha,
Michael Heilemann
http://binarybonsai.com
chrisjdavis
wind, so we are going to be firmly in the Apple camp on this one, to a
point.
We will minimize API changes along the way, which will allow us to
change everything behind the API, and do new an shiny things.
I hope that makes sense.
Chris
Owen Winkler
>
> One or our main desires with Habari was to cast legacy concerns to the
> wind, so we are going to be firmly in the Apple camp on this one, to a
> point.
+1
> We will minimize API changes along the way, which will allow us to
> change everything behind the API, and do new an shiny things.
I think that's the best way forward. We're packing in so much
flexibility from the start that the API also has to be well-defined to
handle change.
Owen
BlueSaze
community. The larger the community becomes the compatibility issue
will keeps cropping up. I have been with Drupal and Joomla for a long
time and backward compatibility is a major issue. I rem once Drupal
broke the mold by releasing a few features that broke backward
compatibility the forums were flooded with issue's (mostly Newbies) .
Firas Durri
>
> Actually this will become more of a issue When we have a Larger
> community. The larger the community becomes the compatibility issue
> will keeps cropping up. I have been with Drupal and Joomla for a long
> time and backward compatibility is a major issue. I rem once Drupal
> broke the mold by releasing a few features that broke backward
> compatibility the forums were flooded with issue's (mostly Newbies) .
>
It's a balance in the end, and the only question we can decide at this
point is which side of the spectrum we'll default to. Like all fresh
shiny-faced start-from-scratch types we're probably best off deciding
that APIs are contracts and should be phased out slowly after being
clearly deprecated and any undocumented behavior is up for grabs in
terms of how something will function in the future.
The reason this is such a problem is that 'current' plugin/theme
authors are A-list/high-priority users of the software, just as future
extenders and end users are. Which way do you sway? MSFT's business
model for windows depends on "developers, developers, developers" so
they sway towards being conservative.
We really need to step back and reinvent the whole plugin/theme
ecosystem management approach so that it's easy to spot and report
plugins that aren't working with a release candidate, help the
developer fix it, etc.
Actually that's an idea isn't it? Backwards-compat breakage is usually
just about functionality that can be recoded without much
decision-making/fuss. If there's a culture of making sure all 'listed'
plugins/themes are tested and someone does the quick fix if the
maintaining developer doesn't currently have time, and so on, this
ends up being a social problem mostly.
--
Firas Durri | http://firasd.org