Add support for legacy IDE's

[Chris--A]

Create a 'legacy' branch which supports the library format of 1.0.x versions.

[Chris--A]

@bperrybap

There is now a branch legacy which will be updated at the same time as master. I'll start doing development through the develop branch. I have just released version 1.2.0 to get the bug fixes out there.

I'm planning on having the legacy branch as the git method of using the lib, and after a release I'll start adding a zip file to the master branch so people can download it easily.

And I'd be aiming for 1.x.x coverage. 0023 and below are too old and too many differences like you mentioned.

[bperrybap]

I know I brought up support for older IDEs, but it is quite a mixed bag.
And when going back before the latest 1.6.9 there are some major issues in certain IDEs that preclude their use.

For the upcoming hd44780 library I debated long and hard as to whether to actually abandon IDEs prior to ones that support the IDE library manager (1.6.2) and even considered requiring recent IDEs that can detect libraries that use libraries so sketches don't have to have includes for libraries that are only used by other libraries, which moves the bar to 1.6.7
But then because of the major bug in 1.6.8 that would move the bar to 1.6.9

It comes down testing and support as well as an ease of use for the end user.
It is amazing how many arduino uses can flub up installing a library from a zip file, particularly
in the earlier IDEs that don't have the ability to do it from the IDE.
Compounding that, github doesn't have a downloads areas (the main reason openGLCD is on bitbucket) and github creates it's zip name based on git information so you can end up with users creating directories with a different name by default than what it should be - which can create issues, when they accidentally install multiple versions of the library when trying to update the library (yes this has actually happened)

And that is what led me to consider only supporting very recent IDEs so that users could get a nice "easy to use" and a it "just works" experience.
In the end, at least for now, with hd44780 I'm supporting anything 1.x with certain exceptions since certain IDEs are basically unusable and should be avoided.
Also, keep in mind that older IDEs have some completely unnecessary naming restrictions that can preclude their use. Characters like _ and . are not allowed in some versions.

These are the "Do not use" versions that I note in the notes for hd44780:

• IDE versions 1.5 to 1.55 (unnecessary file name restrictions, breaks many libraries)
• IDE version 1.6.6 (has function prototyping issues that can break some sketches)
• IDE version 1.6.8 (has serial port issues that breaks on certain boards)

These issues tend to apply to most libraries.

You can read more about some of the IDE issues in the issues section of openGLCD:
https://bitbucket.org/bperrybap/openglcd/wiki/Known%20Issues.wiki#!known-issues

But at some point (after I see a few stable IDE releases after 1.6.9), I might actually just drop the hammer and restrict the libraries to 1.6.9 and newer as having the library manager and the sub library support makes things much easier for the end user.

In terms of actually supporting pre 1.5x IDEs
I think it is fine to abandon pre 1.0 support. The only reason I supported it for so long was that to support ChipKit you had to support MPIDE and MPIDE was based on 0023 and recently has become a hybrid of pre 1.x and post 1.x which makes it extremely difficult to support.
(Some stuff is pre 1.x some post and the defines that are used to detect won't work on MPIDE)
But now ChipKit has a board and core package that work with the recent versions of arduino.cc IDE.
This makes ChipKit support very easy to install as you can now do it all from the arduino.cc IDE.

The latest MPIDE also has issues with linux, in that it won't work on any of the LTS versions of Ubuntu and Mint that are not the most recent LTS package.
I had some big debates with them over this.
So as of now, I have not plans to do any testing on MPIDE and will only test with the board and core package in the Arduino.cc IDE.

I don't do any testing with the Arduino.org IDE.
It isn't that I don't think that that arduino.org guys don't have valid claims to the Arduino name
I think the arduino.cc guys were morons with respect to business practices and how they handled their trademark filings. In fact they even let several of the early ones expire from simply not filing paperwork.
But the arduino.org IDE is far behind the arduino.cc IDE in terms of features.

I also totally abandoned any support for the Maple products very early on.
That product line required using their IDE and they went in and made many changes to the core APIs, some of which were not source code compatible with the mainline arduino.cc IDE.
It was also very difficult to get up and running. For that reason, I just dropped all support for that product line.

[bperrybap]

Argh....
I'm just now going through creating all the documentation and testing for the hd44780 library.
I had forgotten all the mess required to get things working on the older IDEs.
As you start testing with the older IDEs I'm sure you will bump into and find find some craziness required to make it work.

Things like having to re define PROGMEM on the older avr-gcc versions to keep the compiler from barfing out warnings on every single use of progmem or the F() macro and in many cases refusing to link the final image.
There is a simple work around but the Arduino developers never did it. The issue is that there is a bug in the way the AVR libC defined progmem that triggers another bug in the C++ compiler.

One of the painful areas, is installation instructions. Things are nice and easy when using the library manager. But it gets a bit complicated when having to explain to novices how to do the install, especially since github does not provide a download area for pre-built images. and IDEs prior to 1.0.6 can't install a library from a zip file so the install is completely manual.

Luckily I had already been through it with openGLCD but I'm beginning to question if it is really worth it to support IDE versions prior to IDE 1.6.2 (which is where the library manager comes in)

[Chris--A]

I only plan to try to support down to version 1.0.0, however it may not be possible. Either way, the master branch will remain up to date, and the legacy branch will contain the same thing just a different folder layout.

Luckily I had already been through it with openGLCD but I'm beginning to question if it is really worth it to support IDE versions prior to IDE 1.6.2 (which is where the library manager comes in)

It would be best I think, then it encourages people to use the newer ide (C++11, lib manager) and also gets more 'testers' out there to find bugs in not only our libraries, but the IDE also. I'll try for 1.0.0 and see how it goes anyway. I might put some messages in the code to print out something like:
"Warning: you are using an outdated IDE with a very old compiler."

Also, in the latest build the compiler is going up again, so now we have three over the support range: 4.3.x -> 4.8.1 -> 4.9.6. The Arduino mob are looking at even moving to 5.x.x/6.x.x eventually (there is an issue with tests somewhere) and this would mean breaking changes to the PROGMEM functionality also.
But I doubt that would happen for a while.