Re: [wtp-dev] proposed package naming convention to distinguish 'work in

[Arthur Ryman <ryman@xxxxxxxxxx>]

David,

The discussion is about released code.
We can set expectations that all code except API, is subject to change.

Arthur Ryman,
Rational Desktop Tools Development

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
intranet: http://labweb.torolab.ibm.com/DRY6/

David M Williams <david_williams@xxxxxxxxxx>
Sent by: wtp-dev-admin@xxxxxxxxxxx

03/08/2005 01:23 PM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx
cc
Subject	Re: [wtp-dev] proposed package naming convention to distinguish 'work in progress' API

I've had lots of discussions with development teams, and almost all of
them like the idea of kind of "degree of internal" naming. I
think, however, its main value is to the development teams and those working
*real* close to the development teams. 

But ... are we talking about released code? Or just temporary, within-milestone
names? If the latter, then nevermind this post. If the former, I'd be hesitant
to have a project standard, for the simple reason that as a project (and
PMC) our promise to clients is only for the APIs (not "almost APIs"
or "API in the future"). 

I say this partially from experience with early releases of Eclipse, and
some statements from some of those developers of "oh, yes, we intended
that internal package to be API in the future", but by the next release,
the way of providing the function as a supported API was completely changed
(rightly so) , was not a mere rename (rightly so) and caused upstream clients
some unexpected re-work (rightly so). So, in other words, no matter how
good our intent of "we want to make this API in the future" there's
really no good way to predict what it would be like in a future release,
or how much re-work from clients it would entail, once it was truly designed
and made platform quality ... so, we have to be very careful to give the
right message to clients that a "provisional" API is in no way
a partial API or promise for future API. 

Having made all these cautionary remarks about correctly setting client
expectations, I'll emphasize I think it's great that teams using something
in addition to "internal" to make their package names more meaningful
to themselves and their clients. 

David

Arthur Ryman <ryman@xxxxxxxxxx>
Sent by: wtp-dev-admin@xxxxxxxxxxx

03/08/2005 12:16 PM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx, Jim des Rivieres <Jim_des_Rivieres@xxxxxxxxxx>
cc	wtp-dev@xxxxxxxxxxx, wtp-dev-admin@xxxxxxxxxxx
Subject	Re: [wtp-dev] proposed package naming convention to distinguish 'work in progress' API

Craig, 

+1 

I think it is very useful to drawn the distinction between code that is
truly internal and code that is on course to become API. Using "provisional"
instead of "internal" works for me. 

Another approach might be to use something like "candidateapi"
for candidate APIs, and then change that to "api" when the API
is ready. 

Jeem - any thoughts? 

Arthur Ryman,
Rational Desktop Tools Development

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
intranet: http://labweb.torolab.ibm.com/DRY6/

Craig Salter/Toronto/IBM@IBMCA
Sent by: wtp-dev-admin@xxxxxxxxxxx

03/08/2005 01:37 AM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx
cc
Subject	[wtp-dev] proposed package naming convention to distinguish 'work in progress' API

Hi, 

Currently we use 'internal' package names to indicate that code is not
supported API.   I know many of us have code that is 'work in progress'
API and though its too soon to expose this as 'fully supported API' its
seems useful to be able to distinguish these preliminary API's from the
rest of our our 'internal' code.  I'd like to propose that we use
'provisional' in our package names to indicate this sort of work in progress
API.  I think this will help our customers get a better feel for what
parts of our code we eventually intend to promote as API and what parts
we consider to be truly internal. 

Any opinions? 

thanks

Craig


Craig Salter
Rational Studio XML Web Services
Internal Mail: D3/RY6/8200 /MKM 
Phone: (905) 413-3918  TL: 969-3918 FAX: (905) 413-4920
Internet: csalter@xxxxxxxxxx     Notes: Craig Salter/Toronto/IBM@IBMCA