We have a horrible time following good release early and often practices and the more we go, the worst.
You all know that I'm not happy with the current FOM design because of the based on the concept of "let's try to do everything", while I favor the approach "do the simplest thing that can possibly work" and add stuff as you go. The FOM will be a critical contract for Cocoon 2.1 usage. Just like the sitemap was for Cocoon 2.0. We spent 18 months designing the sitemap contract. It paid off. No, I don't want to postpone 2.1 for 18 months to cleanup the FOM, also because few people will use it if it's considered alpha stuff. Chris suggests we release 2.1 without bothering the FOM because it will need time to adjust anyway. I agree, but what really worries me is the fact that we *already* know it's going to change radically and releasing such a bad contract is not going to be good publicity for cocoon in general from contract solidity perspective. you can mark it as beta as much as you like, but people are going to discover it, fall in love with it, use it for testing, then pressured by their bosses, put it in production, then ask support for it, or at least a back compatibility layer. Do you really want to force our users to go thru this? I don't. Cocoon is highly respected for its contract solidity. At the same time, I don't want to block the release further. So there is the plan: 1) I will try to patch the FOM for the proposed plan for June 24th. 2) If I can't do it, we release with what we have and we state loud and clear that the FOM contract should be considered unstable and that might change in future releases. What do you think? -- Stefano.
