[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] HEAD open for 4.0 development?
|
Hi Remy,
Remy Chi Jian Suen wrote:
On Fri, Jun 19, 2009 at 1:40 PM, Scott Lewis<slewis@xxxxxxxxxxxxxxxxx> wrote:
1) We have been asked by the RT PMC to consider slowing down our major
release cycles (i.e. going to minor releases rather than yearly major
releases).
I don't remember this. Was this posted to ecf-dev?
No. It was communicated to me when I submitted our release review
slides to the rt-pmc.
AFAIK, nothing
like this has been done with EF projects, and so I don't think there is any
precedent for it...although that doesn't mean that it's necessarily
impossible. Anyone have thoughts about this?
I suppose it all comes down to communicating with the public. If we
call the next release 3.1 but breaking API changes were introduced in
some subset of bundles, how will the community know about this?
Well, as you say it would involve communication.
I've always been of the opinion that we're moving too fast.
Personally, I don't think the changes that have occurred in the past
two years have warranted a major version change. I think the only
reason this has been done is because of API breakage. Nonetheless,
when I realized we were going to release 2.0, I was somewhat
surprised. And when I realized the next one was going to be 3.0, I was
even more surprised. When a major release is made, I think the
assumption is that drastic changes have been introduced. However,
since 1.0, I think the only "big" things that have happened is the
evolution of the filetransfer and discovery APIs and providers and the
introduction of Cola.
I think the difficulty is in the definition of 'big'. You have a
certain view about what constitutes a 'big' change, but this isn't
necessarily representative of others...e.g. other committers,
contributors, consumers, etc.
For the platform (the natural reference point for everyone at EF,
IMHO)...'big' is world-changing (e.g. e4). But that's because a) it's
been around a much longer time; b) has many more adopters; c) any change
at all affects many people. So naturally it makes sense to move rather
slowly at this point. But there is a penalty to this...and that's that
it is very difficult for the platform (for example), to introduce
*really* big changes at this point.
A major version change causes a certain amount of hype and if
expectations are not met, these version numbers may lose their real
meaning of API evolution and feature enhancements and turn into
marketing numbers.
True....but the other side of the marketing coin is true also...that is,
if we can't move quickly enough in our own relevant area then we are
also likely to suffer in marketing terms...that is, we won't be 'new and
cool'.
Scott
