Author Topic: SDK API changes  (Read 17962 times)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: SDK API changes
« Reply #15 on: December 14, 2005, 02:46:02 pm »
Major versions (the first number in the version) are allowed to change the API from previous major versions. Minor versions are only allowed to make minor changes to the API that should be relatively easy for plugin developers to update their plugins for.

Unfortunately I don't know the SDK that well. One suggestion I have is making the first call to a plugin a request for the SDK version number that was used to program the plugin. Like was the case with the update from Firefox 1.0 to 1.5, plugin developers will have to update what this function returns from release to release, but that is not hard. Most Firefox 1.0 plugins worked in 1.5 by exactly this type of change. Minor versions are also allowed to add new features to the SDK that do not interfere with the already existing SDK. Not interfering is the key to the idea that plugins will probably work after a minor version update, with little to no changes before the code works.

There was the suggestion to move to an entirely new concept for events and event bindings for 2.0. That alone would require all plugins be updated for 2.0. The fulll major version release cycle (dev, beta, RC, final) is designed to work around such requirements and give plenty of time to allow updating to use the new SDK changes.

All that said, the only changes you need to make before RC3 are:
* if you plan to release a minor version between 1.0 and 2.0 (such as 1.1 or 1.5) you will need to make changes now with the understanding that only very small SDK changes (excluding additions) are allowed between minor versions.
* you need a way to verify the SDK version that a plugin is designed to work with so you don't have C::B 2.0 trying to load a 1.0 plugin that clearly won't work. You can implement this with either:
- a function that returns single number (string) of the form "1.0" or "major.minor" that a plugin is designed to work with.
- a function that returns a range of the form "1.0-1.5" that a plugin is designed to work with.
- two functions, one that returns the minimum and one that returns the maximum.

Keep in mind that these functions should never change. A call by any future C::B version to this function will quickly let C::B know whether or not it should try to load the plugin.

There is no obligation to make changes to the SDK that you know will not appear until the 2.0 development cycle. Since we technically are already in RC stage, I suggest holding off on making any such changes now that are not trivial.

If we come out of 1.0 ready to add/change a bunch of things, there is nothing stopping us from starting development on 2.0 immediately, so we won't be hindered by obligations to not change the SDK. Make 2.0 development a branch in the repository so 1.x development can continue with bug fix patches in the trunk, and merge the branch with the trunk when we are ready for 2.0 Beta 1. Before that merge, branch the final trunk version of the 1.x code so any future major bugfixes that it needs can still be made, but for the most part we'll be able to "abandon" it at that point.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: SDK API changes
« Reply #16 on: December 14, 2005, 02:51:16 pm »
Massive changes are best done early. The earlier, the less dependencies that break.

Massive changes are best done early. Early before the release candidate stage though. Good practice tells that the final release should be identical to the final release candidate. This means we feel that the release candidate is bug-free enough to consider it ready for everyone. Only minor changes should be made before RC3 so it isn't too hard to say "yes, we have checked RC3 for bugs and feel that it is ready to be called 1.0". If we find showstopper bugs, we have to go to RC4 at that point, test them, and then call RC4 final. Andd so on...
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: SDK API changes
« Reply #17 on: December 14, 2005, 03:04:14 pm »
Oh, you should also add a way to let a user know that a new version is available, with the option to notify on all (beta, RC, and final) new releases, or just for new final releases.

You don't need it able to automatically download and install the update, just let them know. :)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: SDK API changes
« Reply #18 on: December 14, 2005, 03:10:52 pm »
Oh, you should also add a way to let a user know that a new version is available

AFAIK, when a new version is available, it is displayed in the C::B website and a new message is posted in the forum. What would be interesting would be to add a "check updates" option in Settings or Help menu of C::B.

Michael

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: SDK API changes
« Reply #19 on: December 14, 2005, 03:40:45 pm »
Ah, I see you changed yours back. Much better :).
Bah...
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: SDK API changes
« Reply #20 on: December 14, 2005, 04:01:53 pm »
Well, hope nobody complains about the modified version then... :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Make the changes now!
« Reply #21 on: December 14, 2005, 05:20:54 pm »
I vote for making the changes now. *JUST* make a tag before it's actually done, or we could be in big trouble! (read-as: I can't compile CVS with RC2! :lol: )

And yes, If we're gonna make changes to the SDK, better be *before* version 1.0 is released officially. That'll save us from a lot of headaches later.

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: SDK API changes
« Reply #22 on: December 14, 2005, 05:52:23 pm »
Well, hope nobody complains about the modified version then... :)

just updated ! works fine !!! thanks

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: SDK API changes
« Reply #23 on: December 14, 2005, 06:03:24 pm »
Well, hope nobody complains about the modified version then... :)

just updated ! works fine !!! thanks

Ah, I did not mean that at all :)  I meant the modified version of Yiannis' avatar which I made. :lol:
But yes, the projects have been updated too :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: SDK API changes
« Reply #24 on: December 14, 2005, 06:05:22 pm »
...Ah, I did not mean that at all :)  I meant the modified version of Yiannis' avatar which I made. :lol:
But yes, the projects have been updated too :)
oops  :shock:
thread switching took place only in my mind  :)