[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] HEAD open for 4.0 development?
|
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