<touched send by mistake> many classes are "polluted" by properties and view/model interaction, and view styles are also APIs, even though the methods are intended to be hidden. This is the nature of the "accepted approach" and perhaps not too much can be done about it.
In the long term, I expect a stable 2.0 emerge that follows the general comaptibility guidelines and the cruft has been removed. Once that happen, I think we should be much more stringent than now. -- Niclas On Sep 18, 2009 9:38 PM, "Niclas Hedhman" <[email protected]> wrote: Well, all this is a lot of personal choice. I'm pretty concious about these things myself, and wouldn't do a 1.0 release until I feel the APIs are fairly stable from a compatibility point of view. In a 0.x series you can change as much as you like. For example, we are currently about to release Qi4j 1.0, but that represents 4th generation of complete rewrites and API changes, plus numerous incompatible smaller changes along the way. Now, for Pivot, I think the current 1.x is really a 0.x series, as I think that there should not be backward incompatible changes within 1.x. And I have no problem with this, as Wicket is doing the same thing in reality. One additional problem for both Pivot and Wicket is that the API is not very clear, and in fact many classes > > On Sep 18, 2009 7:18 PM, "Sandro Martini" <[email protected]> wrote: > > Hi, > My 2c is that thus far, we've been releasing minor versions (1.1, 1.2, etc.) > every 3-4 months, ... > > Ok, my experience is mainly on big frameworks, mainly web frameworks, > where a major release (... > That would put a 1.4 release tag around early Dec for a > deployment in late Dec or early Jan. I... > > I understand your point of view, and I agree that this is a not-so-big > project (as a codebase...
