You bring up a very valid and good scenario. In such cases, we could choose to branch from the last release's tag and apply fixes to that [stable] branch as well, so as to release a 1.3.1 while continuing to work on a 1.4. I think this methodology would serve us well, though probably only once the codebase stabilizes some more. Most of the recent (last month) API changes have been due to working through the tutorials, and as such, I anticipate that they'll stabilize a lot once we finish our push to provide better documentation.
-T On Fri, Sep 18, 2009 at 7:18 AM, 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, and that that's about right. It's generally good > practice > > in open source to release more often than you do in traditional closed > source software. > 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 also don't see us releasing > another > > major version (2.0, 3.0, etc.) at all until something big changes in the > > platform -- if you look at the roadmap in JIRA, the 2.0 release has some > > really grand things, like a whole new look & feel. Until then, I see us > > releasing 1.10, 1.11, etc. if we have to. > > 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 >
