Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] HEAD open for 4.0 development?

Scott Lewis 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).  They are representative of some consumers.

Do you have more details about the request? Or for sake of openness
would be possible for those parties to respond to this email thread?

> 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).

That is not entirely true. We cannot add methods in interfaces which
clients may subclass [1].

[...]

> 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).

If consumers have good reason to not follow our major release, they are
free to stay on earlier releases and help maintaining them. :-)

> 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?

This sounds like we turn an ECF release into a micro release train much
like Galileo is. Personally I like the idea. It truly exploits the power
of component based software engineering.

Markus

[1]
http://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method


Back to the top