As far as backward compatibility modes go and their value, I think you need to rethink that one.
There is a simple reason why Microsoft's XP is still so popular: Backwards compatibility.
Businesses and end users all over the world have spent lots of time, effort, and money to get their
favorite applications up and working and many have applications that simply either don't work on the newer OS's
or don't work like they used to.
Backwards compatibility is very important.
I guess my point really was that I see a very rocky road ahead with more non backward
compatible changes being necessary as the non AVR support is rolled in
and the current 1.0 release really doesn't leave behind a stable platform for the AVR users.
It would have been nice to have had at least one stable 1.x "officially released"
platform that users could use while the changes and new feature updates were being bounced around
including adding support for the new non AVR processors.
(0022 was in place for nearly a year and would have made a great 1.0 release)
New capabilities could be done in some other release path where all kinds of non 1.0 backward compatible changes could
be made using the benefit of many years of experience that has come from the current Arduino
development.
BTW,
I was assuming that a "1.1" release would completely and immediately obsolete 1.0 and that any
non 1.x compatible changes could move forward to say a 2.x development tree.
My real preference would call 1.0 a "mulligan". Obliterate it. Make 0023 1.0 and make the current 1.0 a 1.1beta release.
It is a philosophy thing. It is a "don't look back", "you always want the latest stuff I'm giving you" mindset.
I don't subscribe to this mindset.
That type of mindset can be very chaotic for end users and 3rd party developers kind of like what we are seeing today with 1.0
I believe that it is impossible as a developer to ever know or
determine exactly what users need and how they will use things.
Because of that, you must be very flexible and work very hard not to break things especially
things that have been in place for years.
Occasionally, yes it is necessary, but when you do have to break something, you want to do it
in a way that minimizes the pain felt by the install base. That usually means providing an easy
transition path that often means providing some backward compatibility capabilities to give
the user base time to catch up.
Look at the release timing here:
0022 is release 2010-12-24
0023 is released 2011-11-09
1.0 is released 2011-11-30
While I know that 1.0 RC candidates were out for sometime prior to the 1.0 release
the bulk of the Arduino community had no idea about the significance of the changes coming.
It was also very odd that the 0023 release came out after some of the 1.0 candidates.
The 1.0 release took something that was fairly stable, tossed in lots of new things, and made
some changes that broke 100% of the existing install base (for libraries) just before going from essentially
a "beta" to a final release.
That is a very rare thing to do in the software business.
Especially a mere 3 weeks after a previous release.
It would have been nice to have at least one official release before everything was broken.
i.e. make 0023 the 1.0 release and move the current 1.0 release to 1.1beta
That solves everything. People get an official 1.0 release that works with all the install base of code
and those that want to experiment with 1.1beta for the new features can do so but could drop back to 1.0
if there are any issues for them.
--- bill