> Also, getting 2.0 out the door would have (almost) no impact on the > addition of new features. I would like to move to a release > model were > we can release more often, with smaller changes between > releases. This > way, it should be much easier to do upgrades and bugfixes. I guess, > overall, it could mean that development can speed up, because changes > can be smaller. > If anybody disagrees with this: please yell and tell me why :)
Rapid development sounds good, but it would also be nice to have a set of target milestones so that people can know what's coming out and approx when. I guess the one thing that stands out to me which worries me a bit is schema changes, and even the addition of new tables, etc. The change for v1.x -> 2.0 is not likely to be a trivial one for me. I'm currently sitting on about 110G of mail and I know the changeover is going to be 'fun'. A once-every-so-often schema change is fine, but if you have to do it every 1-2 months just to keep current with the current version, then it starts becoming a bit of an admin burden. This is especially true if security patches are not applied to the previous versions (e.g if working on 2.4 and 2.2, 2.3 are not patched, etc). There probably needs to be a better way to track schema changes and updates to databsae required between versions. A "What's changed between v1.2 and 2.0" and "What's changed between v2.0 and 2.1" doc; which lists the SQL/scripts that need to be run to upgrade things and the schema changes made. Of course if you can avoid schema changes to more major versions 2.0, 2.5, 3.0, etc -- even better. Maybe a project plan would help here - and the schema could be set up with the necessary fields. Don't let the above rain on the development parade :) Just pointing out some of the concerns from my end relating to the 'cost' of upgrades. Cheers, Mark.
