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 (with some incompatibility in code) is every 12 / 18 or more months, take for example Struts, Spring, Wicket, etc ... > 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), but take a look at this scenario: after some weeks from the pivot release, a developer start to develop an application based on Pivot, say on the 1.3 . After some other weeks, a (little :-) ) bug is found in the 1.3, and the custom application need that fix. But in the meantime we are already on the next release (that contains incompatibilities with the previous, but probably this is not a major like 2.0, but only a medium release 1.4 or another 1.x), and no maintenance release for the 1.3 will be released. So our user (one or many) can: - modify pivot source code, and maybe sending back to us for some fixes - use a unstable version, taken from trunk, but in many companies this is not wanted (right) - wait the next release: change the (maybe already working code) to ensure all works good, in the case that some non-compatible change has been introduced in the meantime -- note: the new release could have old bugs fixed, but usually has new bugs, so what is better: a old or a new bug ? Probably none, but in this case what choice ... - other ? I think in our Release Policy (if any) we should handle these situations. So at least one maintenance sub-release could be enough for most cases. Staying on the same field of RIAs, for example what are doing Adobe (Flex), and Microsoft (Silverlight) ? Major releases every 12 / 18 or more months, and many mid releases, any with their maintenance sub-releases. My effort in this project is limited compared to that of Greg and Todd, so for me there aren't problems, but i think that we should improve cases like this. Comments ? Mentors, in your experience on Apache Projects what can you suggest to us ? Sandro
