Re: [ecf-dev] HEAD open for 4.0 development?

[Christian Campo <christian.campo@xxxxxxxxxxxx>]

Am 22.06.2009 um 17:32 schrieb Markus Alexander Kuppe:

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

Did you considered reading the public rt-pmc mailing list archive ? I  
saw the request over there from Tom Watson on rt-pmc on the 29.Mai 20:22
I inline the mail to save you that:
-----
Slides look good to me.

My only comment is on the future plans for ECF 4.0. Do you have a  
major release each year with a major version increase? Do you always  
anticipate on making breaking changes for each yearly release? My  
concern is for the ECF bundles which are now part of the Equinox  
release. Down in the core platform we tend to keep the major version  
of our bundles for many releases. I am wondering how much breaking  
changes we should anticipate in our dependencies on ECF.

This comment should not hold up your submission of the slides.

Tom
-----
> > 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
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev