We certainly haven’t been doing that
in the past, except for bugs. Is that a new policy? I wasn’t under
impression that we needed bugs tracking all of the feature work. It’s
certainly the case that everything released for a service-pack should by
definition refer to bugs as we don’t allow feature work in a service
back, but are we extending that to major feature releases like 2.0.?
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Arthur Ryman
Sent: Friday, September 22, 2006
12:12 PM
To: General
discussion of project-wide or architectural issues.
Cc: General
discussion of project-wide or architectural issues.;
wtp-dev-bounces@xxxxxxxxxxx
Subject: RE: [wtp-dev] Notice of
upcoming change in provisional api
Kosta,
Thx.
Just
to strengthen David's remarks, ANY code change should have a bugzilla and the
number should go into the commit comment. This lets us understand changes and
generate "What's Fixed" reports for each release.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
"Konstantin
Komissarchik" <kosta@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
09/21/2006 06:37 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
|
RE: [wtp-dev] Notice of upcoming change in
provisional api
|
|
So much for good intentions. I rolled back those
changes and opened bugs against the three components that use deprecated FPF
api.
wst.web : https://bugs.eclipse.org/bugs/show_bug.cgi?id=158231
jst.j2ee: https://bugs.eclipse.org/bugs/show_bug.cgi?id=158229
jst.ws: https://bugs.eclipse.org/bugs/show_bug.cgi?id=158230
On a somewhat related topic, 25000 (yes that’s
thousand) warming messages are flagged if you load all of wtp product plugins
into a workspace. Is anyone besides me embarrassed by this?
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Thursday, September 21, 2006 1:10 PM
To: General discussion of project-wide or
architectural issues.
Subject: RE: [wtp-dev] Notice of upcoming change in provisional api
Konstantin,
Thanks for splitting up the changes and waiting for the code-change process to
be established.
But, as you are leading the pack here, you've revealed two other issues
(early):
1. Some of the changes you made to other team's plugins (to move them off the
deprecated API) are the correct changes to
make, but the timing is wrong. Many (if not all) of those teams have not
branched their plugins for 1.5 vs 2.0, so what ever is
checked into HEAD can be confusing should they need to make an emergency fix
for 1.5.1 ... or, might make it confusing
if or when they do go to split streams for 1.5.2, which may not be split
immediately, or, what ever.
So, can you please back out those changes made to unbranched plugins? Feel free
to chat with those
component leads if you have questions on how to get back to their 1.5.1 state.
2. Plus, you've revealed, that another part of the documented process should be
a bug should be open when changes are
made to other's code. Usually it is much appreciated when you fix other's code,
as in this case, but, it is nice to have a
clear bugzilla where the changes, reasons, timing, etc., are all documented. I'm
not sure if you had a general "cleanup"
bug, but, it wasn't immediately obvious, so, thought I'd include this note here
so we all would learn the importance of
bugzilla and tracking changes.
Thanks again, both for your general contributions and these specific fixes.
"Konstantin
Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
09/21/2006 12:55 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
|
RE: [wtp-dev] Notice of upcoming change in
provisional api
|
|
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_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev