Hello, thank you for your contribution to this module, it is a great help. I have a question regarding your use of different branches to support different major versions of Open Flash Charts. Will the API change depending on the branch version? This may be a problem for example if I want to require the Open Flash Charts module, but my code expects the 2.x Branch, and the user downloads the 3.x Branch, it will cause errors. Is this a problem, or is there a work around?

Comments

jvandervort’s picture

jvandervort commented
Status: Active » Fixed

Not so much. The new OFC2 in 6.x-3.x-dev uses a new experimental api (subject to change).
It is still chasing a changing OFC2 which hasn't slowed down yet. Currently the docs aren't up to date,
but you can use these:

http://drupal.org/node/423020

Anonymous’s picture

Anonymous (not verified) commented

So, can users safely interchange OFC2 and OFC using the same api code? Or will there need to be different code made for different versions? And if there needs to be different code made depending on the version, how can the module developers specify which version is needed?

redndahead’s picture

redndahead commented

Usually people specify it on the module page on d.o. Something like Version 3.x requires OFC 2.x and version 4.x requires OFC 3.x

It's fairly common as api's change regularly. If it makes you feel better our plan is to follow the apis of Open Flash Chart so we should only change as often as Open Flash Chart changes.

Anonymous’s picture

Anonymous (not verified) commented

The reason I mention this is because module developers may want to mark your Open Flash Chart API module as a required module, because they have written code using your API to make charts. But if the API changes from OFC API 2.x and OFC API 3.x, then the modules will break if the users have the wrong version. It would be easier if this module was split into two modules, one for OFC 1, and another for OFC 2, if they will use different APIs. This will make it more uniform for developers so they can specify which version they wrote the code for in the .info file, and there won't be any confusion or nasty errors. If your API won't be changed though, then this isn't an issue.

-Leighton

redndahead’s picture

redndahead commented

I understand your concern. Unfortunately drupal does not allow us to specify the version number when specifying compatibility. Your suggestion to split into 2 different module I don't think would be the best option. As a module that provides an api it is subject to change and the best way we can differentiate that change is to change the major version number. Sometimes api's change for one reason or another and either you can move along with the new version numbers or you have to specify on your project page which one is best. Sorry for the inconvenience.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.