Plans and Priorities
I think excellent documentation, tooling, testing, bugfixes, porting, libraries, and C API hardware completeness are good goals, in roughly that order.
I for one have zero intention of supporting a GUI like the Maple IDE, and will pull documentation reference to it out ASAP.
I for one am also not particularly interested in working on the USB stack in the near future, which includes the DFU bootloader. I propose finding an open source replacement for the maple-bootloader on STM32F1 chips, even if that replacement isn't built on libmaple/librambutan. I'm even tempted to pull out the entire usb and SerialUSB framework and focus on ethernet and open hardware designs to get around the need for a USB bootloader (eg, using monolithic USB chips such as those from FTDI, or a companion chip like the Black Magic Probe or ST-LINK).
I am ambivalent about the Wirish C++ API. I would be interested in building new high-level systems on top of the C API, but it is impossible not to acknowledge the large world of libraries using the Arduino API. It seems like the Arduino API may have matured in the past 5+ years and it might be more reasonable to rebase on top of that. Wiring also did a 1.0 release in the intervening years with a new API to look at (including a C API?).
mbolivar recommends looking at the CMSIS API wrappers. I have gotten feedback from other folks that lack of support for sleep modes and power management is a serious weak spot for libmaple.
v0.0.13: This is the most recent development effort from the Leaflabs team years ago. There are many FIXMEs referencing this release target in the source code.
For librambutan, I propose this as a first small bugfix and cleanup release, with few significant changes. This would basically be a normal libmaple release.
v0.1: There are also some references to a 0.1.0 release in the source code, mostly having to do with deprecating APIs and making larger refactors.
For librambutan, I propose punting most of these changes to an 0.2.0 release instead, and have 0.1.0 be a refactor and port release: merge support for STM32F4, move ./libraries/ into a seperate repository, and extensively rework the reference documentation.
v0.2 Proposed librambutan API cleanup release.
v0.3+: Proposed librambutan "long-term stable" release, still (mostly) libmaple API compatible.
v1.0.0: Proposed release target for librambutan that would rename directories, paths, build tools, and API from libmaple to librambutan. Also an opportunity for other large and backwards incompatible changes to the API. Not clear if making these sorts of changes would ever be a good idea though... they usually aren't for projects? Very speculative.