As I mentioned earlier, I am not really interested in the release version per se, but primary in the time to market and secondarily on what it means in terms of maintenance.
As in all things, the key is balance. Release often is guaranteed way of delivering value to users, releasing too often may send out the wrong message (is it just me, or people tend to become uneasy with very often major releases?). Also releasing very often means, that as a community we will be supporting each major release for a small period of time, or we will need to increase the number of major versions we support at any given time. Do we have the luxury to do so? For example, let's assume that we go for a 4.x in say 3 months.... It has proven a bit hard to maintain the long living 3.x branch along with 2.x (module restructures made it not trivial to just cherry-pick fixes from one branch to the other). If we add a third branch into the mix, it will become even harder. So what are we supposed to do here? Push the release back 6 - 12 months, or until we decide we no longer need to support 2.x? In that case we could hold of creating a 4.x branch until we get near that time (to avoid the maintenance overhead). We could use this time and follow Dan's suggestion about letting other projects adopt the feature changes. But still it does sound like a long time which is meant to become even longer as "new features" will pile up for 4.x. Thoughts? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
