Connect IQ versions

Connect IQ is trying to attempt to mimic other app systems as much as possible, mostly because smarter people than us have made these systems in the past and they're doing okay for themselves. Let's review how the glowing rectangles do it:

* Apple has created a software platform that works across all devices they are still supporting. They control all devices, and they all mostly get the same platform except when it makes sense for a device not to (example: Siri not being back ported to certain devices because it was a feature to get people to upgrade). Once a year they put out a developer beta and tell people to upgrade their apps to support it or get out of town.
* Android has major releases every year, and minor release every year. Every device gets an upgrade when the OEM decides it will. Developers try to support the most popular release, which is rarely the most recent one.

Now, lets talk about programming languages. As we all know, in the history of Python, Ruby, and Java, there have never been any breaking changes ever. That is why you never get any notifications from Java in your toolbar telling you that it needs an upgrade. Oh wait no, they change and evolve all the time. There are holy wars between versions of Python, Ruby switched from interpreted to bytecode interpreted, and don't get me started on Visual Basic!

Connect IQ lives in a sweet spot where we have the issues of all these approaches. Like Apple, we control all the devices that CIQ is released on. Unlike Apple, they're not all glowing rectangles. Heck, I can't even say they'll all be watches (don't read too deep into that people) (or that either), nor can I tell you two weeks after launch we will be able to back port all 2.0 changes into 1.0 products. Some APIs will be based on new hardware that older products don't have, others may not be applicable. Also, remember that time that your iPhone said "iOS 8 is available, but you need to delete all your photos to install it?". Imagine if instead of "photos" I said "product features". We pack our flash pretty tight with all the things you love about the product, and I currently can't say future CIQ features will fit in the future. Finally, lets face it - Monkey C will evolve. Java versions are not backwards compatible, and some day we'll do something silly like add lambdas or inner classes and then the whole bytecode goes craaazzaahh!!!

So, it's complicated. After reading all of the above you're probably ready to (a) argue every point I just made in this thread, and (b) decided the situation is hopeless. But fear not! The Alpha Monkey loves all developers who use this crazy system, and has tried to create some rules:

Lets start with how we are approaching the SDK:

A Connect IQ micro release (x.y.Z) can have :

• Bug fixes
  
• New APIs to support bug fixes
  

A Connect IQ minor release (x.Y.z) can have:

• API additions (new modules, new APIs)
  
• API deprecations (Shows up in documentation)
  
• Bug fixes
  

A Connect IQ major release (X.y.z) can have:

• New Monkey C language/byte code interpreter features
  
• API additions
  
• API deprecations (Shows up in documentation)
  
• API removals (should be a last resort)
  

This is an attempt to show that we won't be changing everything on you always; we'll reserve that for big releases. For now, the products will get updates according to their DR schedule, but all devices are not going to stay on the same CIQ version. The CIQ team will try to make it easy for them to get the latest bug fixes, but there is no guarantee that version 1 devices will all pull up to version 2; they'll be handled on a device by device basis. This sounds terrible for developers, right? Well, hopefully not. Unlike iOS or Android, Connect IQ build binaries for each product. Unlike any other system it is the toolchain's job to generate executables for each device selected. The plan is to ensure that the Monkey C compiler can generate bytecode compatible for a given device. So bytecode incompatibilities and evolution can be handled at build time. Some language features won't get backported, and at compiler time we can flag an error that a particular feature doesn't work for a particular device. This is similar to trying to use new Java features when specifying a backwards compatibility flag. API support can't be found via the compiler (durn dynamically typed languages...) but will be testable at runtime using 'has' tests, which hopefully are only necessary when an API is documented to be missing. Finally we're also working on simulating API compatibility in the simulator, and working in a unit testing framework into the simulator as well. Going forward these will be essential for testing product API compatibilities. These things take time, so bear with us as we work on them. Aside: where we have a hole is handling DR releases. Since DR's come via the internet, there isn't the guarantees that a user has the up to date stuff. Still working that one out; we might allow developers the ability to specify a minimum SDK in the future. Will keep you posted.

This will give you, the developer, the ability to choose if you want to support a product or not. Like Android and Java, some of the new features may only be available on newer products, and you may not want to take advantage of them right away. In other cases, you will want to drop support for an older product. That is your call. What we really want to avoid is people thinking of a FR920XT as a "Connect IQ 1.0 device". Instead, there are FR920 apps, Fenix 3 apps, etc. The CIQ team's job is to make it as easy to write for each device as possible. Should be easy, because these are all solved problems, right?

I could probably write more, but I've spent an hour on this and I'm sure I will not foresee the questions this post will raise. So, I'm going to duck under this Captain America shield while you all throw tomatoes.

-Alpha Monkey