We understand your perspective, but forward looking we do not see the Designer as being the only metadata mechanism for Teiid. Intrinsically tying the release schedules together even from the start does not seem helpful. I also understand that Designer feels pressure to release - however there is no hard requirement to do so. As Ramesh indicates it is already the role of the platform release to put the stamp of quality across all correlated projects in that platform. We do not need to reproduce that effort in the community - it will already flow into the upstream. Also we will have a 6.1.0 release in the unstable spot starting next week. ----- Original Message ----- From: "John Doyle" <jdoyle(a)redhat.com&gt; To: "Ramesh Reddy" <rareddy(a)redhat.com&gt; Cc: "Steven Hawkins" <shawkins(a)redhat.com&gt;, teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org Sent: Thursday, April 23, 2009 7:08:16 AM GMT -06:00 US/Canada Central Subject: Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release ----- "Ramesh Reddy" <rareddy(a)redhat.com&gt; wrote: What about leaving it on the shelf until they're both done? There's no lost time if one project completes it's 6.1 work but it's not 'officially' released and labeled as 6.1 until the other project is ready. We already have stable and unstable slots on the community site, but we're not putting any unstable out there. Put it out there as unstable and move onto features for the next release. When we've reach a level of quality between the two projects, then we label it and post the stable version. Why do we want to have a process that lends itself to the possibility that we will have to patch a release just so users can have tooling that works with it? All of these things are great, and I agree with all of these things. To go further, we have wanted and and even produced alternative tooling (mmshell). Someday there may be several different options for creating the artifacts that Teiid needs, and then your argument becomes much stronger. But I don't think the projects should adopt a process that treats the the individual projects as independent when they aren't yet. We should operate in the circumstances that exist, not the ones we hope to create. Yes, should, but how will we know? How do we validate that? The truth is that we don't know what we're going to be changing in 18 months, and maybe it's going to be disruptive, maybe it's not. I tend to think that if it's not, then we're probably not doing very interesting work. Another uncomfortable truth is that it's very hard to see the full consequences of the changes we make. But either way we should adopt a process that leads to higher quality, and I think that posting the projects as unstable until we validate compatibility achieves that without negative effect.