Hi Aaron, > > "Release early, release often". > > Add to that "maintain compatibility along your production branches"
... or offer a safe and easy way to migrate. > > I'm no friend of collecting a huge number of changes and release rarely - > > I prefer releasing after every single change. > > We have to collect all of the external changes and release them at once. I agree if it's hard to migrate. If a migration leads to long downtimes and requires lot of work by the admin we shouldn't do that, if it's as simple as running a sql script I don't see a problem. No one is forced to use every new version. > There's no slippery slope here. The criteria I'm talking about for changes > prior to 2.0 is very discrete: does the change involve breaking user > interfaces and/or database interfaces? If not, save it for 2.0.x. If so, is > the change something that we're going to want to be already using a year from > now? If not, save it for 2.1. If so, go for it. Of course I'd prefer if the database and command line needs no change for a long time but if you look at the release plan there are several changes yet. Header caching, safe configs in the database etc. That's why I think there's no reason to delay the release any further. Thomas -- http://www.tmueller.com for pgp key (95702B3B)
