I separated the potentially breaking
changes from the part that’s purely additive. I released the additive
part and opened two new bugs to track what still needs to be done after the new
process is established.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=158082
https://bugs.eclipse.org/bugs/show_bug.cgi?id=158083
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: Tuesday, September 19, 2006
8:34 PM
To: General discussion of
project-wide or architectural issues.
Subject: RE: [wtp-dev] Notice of
upcoming change in provisional api
You say "Ample notice" has been given ... and, I assumed you
checked the scan data to confirm not used? But ... remember, ample to us is not
necessarily ample to others ...
[kk] Scan still show usage. I
don’t know whether this means that scans are out of date or that adopters
haven’t migrated off the deprecated api. Multiple messages went out to
the wtp-dev mailing list prior to 1.5 release regarding this. The messages
outlined exactly the api involved and layed out the timeframe (deprecation in
1.5.x and removal in 2.0). The same content was also placed in the ISV docs at
the location that I specified. The code itself was marked with deprecation
syntax where possible and runtime warning messages were provided for some of
the api where deprecation would not be easily apparent. Given the provisional
status of this api, I would consider this “ample notice.”
One suggestion I am going to make is that "new" work or
"big changes" take place in a temporary branch, so potential
reviewers could "get at it" easier for review.
[kk] I think this makese sense, to an
extent, but only for very large and complicated changes. An exception rather
than a rule. The problem is that when we have a major feature release like 2.0
we will have a lot of new functionality being developed. Under the proposed
approach we would have quite a handful of these private branches. That would
create a lot of maintenance overhead in keeping them all up to date. The longer
these branches exist, the more overhead is created and the more risk there is
that some integration mistake will be made.
Another suggestion I'll be making is that we "stage" our
changes, to API or provisional APIs, so that "we change them once",
and that's it. I've heard complaints from adopters that they'd have to change a
little one milestone, then change a little the next milestone, then some the
next milestone ... sometimes that's unavoidable, but our plan should be
to "do it once"... so, it'd be good to release code early in a
milestone, once we knew if we were at a point of "that's it", no more
changes planned.
[kk] I am not sure how practical this
is. A component may need to make multiple api changes during a release for
various separate reasons. With the approach that you are proposing, the first
of these changes would force the component into a branch from which it cannot
emerge until all of the changes for the release are done, which may be towards
the end of the release. We are talking about a branch that may exist for half a
year or longer. That’s very bad. It seems to me that the adopters who
integrate at the level of the milestones should expect incremental changes in
those milestones. If they don’t want to deal with these incremental
changes, perhaps they should be integrating at the level of the releases not at
the level of the milestones.
Are you at that point? Or do you have more changes planned?
[kk] There are certainly further changes
planned for the 2.0 release.
I won't ask what your plans for API are, yet, because then you'd ask me
about Java 5 :) .... which, btw, I'm almost ready to have that discussion too!
[kk] I can answer this. The
status of declaring official api on the faceted project framework component
hinges on four things: (a) ability to use Java 5 language features, (b)
completion of the project to create the common runtime modeling component (aka
elimination of the runtime bridge), (c) settling the question of whether this
code will ever move down to the platform, and (d) resolution of all bugs and
enhancement requests that require api changes. Hopefully all of these will be
resolved by the end of 2.0 and it will be possible to declare api.
So, if you wouldn't mind waiting a bit, then maybe you could be our
first user of the new processes ... and then you could help improve the process
for the next guy?
[But, if its urgent for you to get these in ... doesn't sound like you'd break
adopters and you'd fix some important bugs, so, don't let me slow you down ....
too much :) ]
[kk] I would strongly prefer not to have
to hold on to these changes. I imagine it would take us a while to agree on a
new process and waiting for the process to be resolved would make it rather
difficult for me to make further progress on the 2.0 work items (changes stack
up behind this). The notice mail should provide sufficient information for any
party that’s concerned about this change to conduct a review.
[kk] While we are on the subject,
I’d like to start the discussion of what our policy is going to be
regarding api-breaking changes (I am not talking just provisional api here) for
the 2.0 release. In order to make progress on several of our major work items
(the common runtime modeling framework is one example), it will be necessary to
break api. If we allow this for some components, I wonder whether we should
make a general statement that the 2.0 release is a chance for all the
components to review their api and make the necessary changes. I am not
advocating gratuitous changes here, I am just suggesting that we have come a
long way since our first release and we could all use a chance to take a step
back and apply lessons learned towards bettering our api. A couple of us have
been batting some ideas for mitigating impact to adopters due to this. One idea
is to extend the life of the 1.5.x maintenance line further than it would
normally extend to, say 1.5.6, 1.5.7, etc. This way adopters who are not ready
to absorb api changes can have a release vehicle for important fixes. It may
also be forth it to have a small feature release, say 1.6, to deliver Eclipse
3.3 compatibility and perhaps minimal Java EE 5 support (basically enough so
that we don’t get in the way of development of Java EE 5 apps like we
currently do). In either case, just some ideas to get a discussion going...
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of David M Williams
Sent: Tuesday, September 19, 2006
7:06 PM
To: General discussion of
project-wide or architectural issues.
Subject: Re: [wtp-dev] Notice of
upcoming change in provisional api
Thanks Konstantin, these sound like important changes, and sounds like
you've used care not to break any adopters, but I'll throw in a few
complicating process questions.
You
say "Ample notice" has been given ... and, I assumed you checked the
scan data to confirm not used? But ... remember, ample to us is not necessarily
ample to others ...
Also,
I am in the middle of proposing some new processes governing how we change
code, how we allow proper review, etc. I haven't "published" it yet,
since I asked the PMC for a sanity check
and
make sure I wasn't way off base ... but will hint here at some of the things
I'm suggesting .... I'm not sure they even apply to your cases ... but,
without some review process, no one may ever know ... so, some review
process
would be nice.
One
suggestion I am going to make is that "new" work or "big
changes" take place in a temporary branch, so potential reviewers could
"get at it" easier for review. And, a component team level decision
made as to when ready to go into head.
Another
suggestion I'll be making is that we "stage" our changes, to API or
provisional APIs, so that "we change them once", and that's it. I've
heard complaints from adopters that they'd have to change a little one
milestone, then change a little the next milestone, then some the next
milestone ... sometimes that's unavoidable, but our plan should be to
"do it once"... so, it'd be good to release code early in a
milestone, once we knew if we were at a point of "that's it", no more
changes planned. Are you at that point? Or do you have more changes planned?
I
won't ask what your plans for API are, yet, because then you'd ask me about
Java 5 :) .... which, btw, I'm almost ready to have that discussion too!
So, if
you wouldn't mind waiting a bit, then maybe you could be our first user of the
new processes ... and then you could help improve the process for the next guy?
[But,
if its urgent for you to get these in ... doesn't sound like you'd break
adopters and you'd fix some important bugs, so, don't let me slow you down ....
too much :) ]
"Konstantin Komissarchik"
<kosta@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
09/19/2006
09:21 PM
Please respond
to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[wtp-dev] Notice of upcoming change in provisional api
|
|
This is a notice that a change will be released soon that has potential
to cause breakage to users of the faceted project framework’s provisional
api. The change will be made to the HEAD code stream affecting only the 2.0 release
code line, so there will be plenty of time for the downstream code to react if
it is affected by this change.
The
change has two parts to it:
1. The
api and extension points that have been deprecated during the 1.5.0 release
have been removed. Information about exactly which api has been deprecated and
now removed can be found in the following section of the WTP docs: Web Standard
Tools Developer Guide -> Programmer’s Guide -> Faceted Project
Framework -> New for 1.5. Ample notice has been made given in the past
regarding this.
2. In
order to fix a performance issue described by https://bugs.eclipse.org/bugs/show_bug.cgi?id=146321 some api
changes were necessary in order to remove the assumption embedded in the api
that facet version comparison is always done directly on version string. The
api change allowed the comparison information to be cached thereby improving
performance. The caching also allowed some api improvement to take place
because several methods no longer needed to throw exceptions. I do not
anticipate this change to cause problems for adopters as the affected api is
only infrequently used outside the framework itself. The api usage scan did not
produce any hits.
Both
IProjectFacetVersion and IRuntimeComponentVersion now extend Comparable.
The
following methods no longer throw exceptions:
IProjectFacet.getLatestVersion()
IProjectFacet.getLatestSupportedVersion( IRuntime runtime )
IProjectFacet.getSortedVersions( boolean ascending )
IRuntimeComponentType.getLatestVersion()
IRuntimeComponentType.getSortedVersions( boolean ascending )
The
IVersionExpr.evaluate( String ) method has been replaced with
IVersionExpr.check( Comparable ) method.
-
Konstantin
>>Register
now for BEA World 2006 --- See http://www.bea.com/beaworld<<
_______________________________________________________________________
Notice:
This email message, together with any attachments, may contain
information
of BEA Systems, Inc., its subsidiaries and
affiliated
entities,
that may be confidential, proprietary, copyrighted
and/or
legally
privileged, and is intended solely for the use of the individual
or
entity named in this message. If you are not the intended recipient,
and
have received this message in error, please immediately return this
by
email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev