Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-pmc] RE: MTJ API on M6
Title: MTJ API on M6
Whatever makes most sense to YOU.
 
The one thing you don't want is be stuck with inappropriate API forever because you released it as API prematurely, and then have to do major releases every year which break your consumers every year.
 
Mind you, people can use code from "internal" packages as well. Consumers get latest stuff at the risk of having to adopt their code when things change. They are aware of potential future change. The only thing they do not get there is the promise that backward compatibility will be retained.
 
So my guideline would be: be true about the quality / maturity status of things (APIs) that you intend to give to your clients. If a problem is very well understood, then you might dare make something API without too much review. But often things come up that you had not considered, and adding things later in a backward compatible way may be difficult especially if you did not make the right decisions in the beginning.
 
Do you have anybody on the team who's got experience in API design? Technical tricks like avoiding interfaces to be implemented by clients directly can help a lot. Or, preferring "int" flags over "boolean" flags because the kinds of flags may evelve in the future.
 
In general, the less API you have the fewer problems you can expect in the future :-)
Because public API is always a promise to keeping it stable.
Don't make too many commitments.
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
 
 

From: Paula Gustavo-WGP010 [mailto:wgp010@xxxxxxxxxxxx]
Sent: Donnerstag, 05. März 2009 13:48
To: Oberhuber, Martin
Cc: Santos Marcia-wma111; Kurzke Christian-E11581; Gaff, Doug; DSDP PMC list
Subject: RES: MTJ API on M6

Thanks for your answer.

 

Does it make sense that we on M6 we target to publish what we (MTJ committers) think make sense until M6 and them after that just remove/change some API base on the community input but don’t add any new API?

 

J

gep

 

 

De: Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
Enviada em: quinta-feira, 5 de março de 2009 09:40
Para: Paula Gustavo-WGP010
Cc: Santos Marcia-wma111; Kurzke Christian-E11581; Gaff, Doug; DSDP PMC list
Assunto: RE: MTJ API on M6

 

Hi Gustavo,

 

I see no Galileo Requirement that M6 must be your API freeze.

 

Until M6, you must document any internal non-API that you are consuming from other projects:
http://wiki.eclipse.org/Galileo_Simultaneous_Release#Requirements_For_Participation

 

But that doesn't mean that you cannot modify your own API as long as your project sees fit.

Especially if you have no downstream consumers (but beware... some people might be picking up MTJ commercially, which you do not see!).

 

With RSE, we have been tweaking API until the RC's in the past. I think that especially for an 1.0 release it is important to have the RIGHT API's, and this typically means that you give some time for reviewing them in public.

 

That being said, you better shoot for an M6 API freeze, you better expose as little API as possible (and keep others internal / provisional for now), but if you are not happy with what you have by M6 then feel free to modify it based on community discussions.

 

The overall guideline should be the 3rd golden law of Eclipse:

  "A committer may not, through action or inaction, surprise the membership"

That is, communicate with your Communities what you intend to do, then you're relatively free to do the right thing.

http://www.eclipse.org/projects/dev_process/three-laws-of-eclipse.php

 

Cheers,

--

Martin Oberhuber, Senior Member of Technical Staff, Wind River

Target Management Project Lead, DSDP PMC Member

http://www.eclipse.org/dsdp/tm

 

 

 

From: Paula Gustavo-WGP010 [mailto:wgp010@xxxxxxxxxxxx]
Sent: Donnerstag, 05. März 2009 13:25
To: Oberhuber, Martin
Cc: Santos Marcia-wma111; Kurzke Christian-E11581; Gaff, Doug
Subject: MTJ API on M6

Hi Martin,

My understating from the Eclipse train requirement is that we need to have a MTJ API defined until M6. After M6 we are not suppose to change anything on MTJ API. Since that, we added that to our plan and we are working really hard to make that date. But there are still some APIs that are not yet closed.

I would like to confirm our understanding is correct. If it is, we will leave some APIs to be discussed and added on future releases. If it is not we will have more time to discuss and maybe add them to 1.0. Since there is no other Eclipse project that uses MTJ APIs, maybe it is not a big problem to change/add APIs after M6, isn’t it?

Thanks,

Gustavo

Back to the top