Ah. API changes are supposed to be written up and circulated on [email protected] for comment.
For OL itself, we do try to follow a process as you outline where the old API works with a deprecation warning for at least one release. Perhaps that is not necessary for an incubator component. It seems like it would be a thing to propose with your API and see what comments you get. On 2010-01-22, at 18:27, Antun Karlovac wrote: > Hi Tucker, > > Thanks for the info. I was actually referring to the process for a change > that would make a significant change to the API. > > Do I just make my change and submit the proposal as described in > Code_Review_Process if it's an incubator component? i.e. we don't have to go > through a period where both the new API and the old API would work > concurrently then deprecate the old API, then finally remove it? > > -Antun > > On 1/22/10 3:23 PM, P T Withington wrote: >> The process is documented here: >> >> http://wiki.openlaszlo.org/Code_Review_Process >> >> It's mostly driven by the review tool, documented here: >> >> http://svn.openlaszlo.org/tools/trunk/svn/README.txt >> >> We'd welcome your contribution, so feel free to ask more questions if the >> above is not clear. >> >> On 2010-01-22, at 18:14, Antun Karlovac wrote: >> >>> Hi all, >>> >>> I was working with the fileupload class today and realized that its API is >>> was never really updated to use events. If I remember correctly, this was >>> written before the days of an LZX<event> tag. I filed this bug to track it: >>> >>> http://jira.openlaszlo.org/jira/browse/LPP-8729 >>> >>> Basically, most OpenLaszlo classes that have asynchronous actions send an >>> event to tell you when the action is done. (e.g. lz.dataset.ondata, >>> onerror...). But fileupload is weird - you have to override methods. >>> >>> What's the process for updating this? I can do the work of updating it >>> (there's not a whole lot), but is there an approvals process I'd need to go >>> through? It's an incubator component, which is why I'm volunteering to do >>> it - I'm assuming it'll be a straightforward API that can change in a >>> future release. >>> >>> Thanks, >>> >>> Antun >>
