[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] HEAD open for 4.0 development?
|
Hi Markus,
Markus Alexander Kuppe wrote:
<stuff deleted>
So far I haven't seen comments from our consumer base asking us to slow
down with our release schedule. Thus as long as the majority is fine
with annual major release, I'm +1 for ECF 4.0 in 2010.
We have been doing annual release for a while now and our consumers
probably expect 4.0 in 2010. Keep in mind that we can always release
3.2, 3.3, 3.x if somebody really needs it (granted with CVS this will be
cumbersome, but we might see a better VCS soon).
ECF provider architecture makes it different to Platform and other
projects with a more conservative release schedule. It requires us to
innovate more regularly to support new providers.
For purposes of discussion, I would like to make a few points
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). They are representative of some consumers.
2) A minor release schedule does not prevent us from adding things (both
API and implementation). That is, we can add new api...both in existing
APIs and in completely new APIs, and deprecate existing API if necessary
(actually, for a long discussion about deprecation policy in the
architecture council see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=279539).
3) A major release schedule basically allows us to make breaking API
changes (e.g. method rename, interface/class rename). Essentially this
is any change to full, non-provisional API. Provisional API can be
broken in minor releases.
4) I agree with Markus that we probably don't need as conservative a
release schedule as the platform...at least for all parts of ECF. But
it's an open question to me whether having yearly major releases is
*too* fast...that is, it's going to be hard for people that are
beginning to rely on these APIs to deal with significant breaking
changes (if they turn out to be necessary)...as just about the time they
get/use/develop with an API (say, ECF 3.0), it can/could change (if we
have breaking changes/4.0 release schedule for Helios/next June). This
can/could be very annoying for adopters, and potentially disrupt
adoption (i.e. make it very difficult).
5) It might be possible to have some APIs be on a slower/more stable
release schedule than others...but I'm not sure how this would work.
Say, for example, that we were to commit to having no breaking API
changes in ECF core, ECF filetransfer, and for purposes of argument, ECF
remote services. BUT, we would allow, on a limited basis, breaking API
changes in less 'mature' or more 'faster moving' API (e.g. the call
API). 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?
Anyway...my $0.02.
Others have thoughts/comments? Please speak up.
Scott
