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
