Being the module junkie I am I have acquired some modules over the years which are no longer supported or appear to be no longer supported, so what to do? If I was to write new drivers for these modules would it be OK to share them on something like CodePlex or CodeShare?
For example I really like SolderMonkey’s triple slide module, but it lacks a 4.3 driver, so I built one for my own use, would it be OK to share it with others?
Absolutely! Unless you are the only one who has that module. 
[quote=“Architect”]Absolutely! Unless you are the only one who has that module. :D[/quote]I’ve got more then a few of those too having funded some folks starting up making modules.
@ Duke Nukem - I have a triple slide, and would definitely find it useful to have a more modern driver for it…
Codeshare would love to see your new contributions.
By the way, we will be opening documentation so some community members can add pages. This was always the plan but we are trying to be careful not to have broken links anymore.
What if you started a Git repo that was a collection of all the deprecated module drivers? Then we could fork and send pull requests if we want to add a driver to it. One thing I always found to be more of a hassle than it should have been was rounding up drivers for Gadgeteer modules. Maybe one day we’ll have a Nuget based solution and the world will be perfect but this seems like the next best thing. I know someone (maybe you, Duke…) created something similar for the DFRobot modules. Perhaps that’s the place to start.
I started the DFRobot driver collection on CodePlex and hopefully I will be able to add the music player driver this week, its a matter of finding some time. I didn’t think at the time that I’d have other vendor drivers to do, but maybe its time to think bigger picture and have them all go into one place.
Today I did TripleSlide, ChimpDriver and AddaSlide drivers for 4.1, 4.2 and 4.3 so I guess the question is where to upload those to. I’ve got a stack of modules that I’d like to update the drivers for and will as time permits as well as some more of the DFRobot drivers. I also have a couple of Gadgeteer videos I want to make as well around motors (regular, stepper and servo). Next week I have a user group meeting and a 2 day Azure/Mobile Microsoft thing in Calgary, good thing I’m an unemployed bum right now.
If GHI created a Git repo with the module drivers, about 5 minutes later there would be NuGet packages 
@ ianlee74 - I see SolderMonkey on Github
but it only has a license and a readme files, so perhaps he was going to put them on Git.
What ever we decide on, it has to be able to handle executable files as I’d like to upload the installer for folks who don’t want to build the driver.
@ godefroi so if I uploaded some drivers to Github how long do you think it would take before they were NuGet packages and who would do that?
Feeling bored think I’ll do the SolderMonkey encoder module.
OctoSlide done and Love Electronics Button and LED Array modules done.
Anyone can. For the average project, a “nuget spec” followed by a “nuget pack” will create the package, and then a “nuget push” will publish it to the gallery.
I’d like to create a directory structure like Gadgeteer -> Modules and then directories for each of the vendors that I’ve created drivers for (ie SolderMonkey, Love Electronics etc). Can I do that with Git and what would be the best way to place an executable (the installer) in each so it can be found easily?
You can create any directory structure you like in Git, but Git isn’t really well suited to binaries. I don’t know GitHub’s policy on hosting binaries in a repo, you might want to check there first.
NuGet’s gallery, on the other hand, is both well suited and eager to host your binaries. No installer required. No updates required. No VS integrations required.
With NuGet you lose the installer (not a bad thing as it can be a bit of work for someone not a regular module developer) and therefore lose the designer integration.
With a binary repo you could have an actual installer - but again the effort to maintain that becomes someone’s task.
[ this isn’t the real reason for your post but I’ll say it anyway… From my perspective, I reckon an optimal solution would be to have a “build owner”, someone who had the knowledge and setup to manage older drivers and helped move them forward into newer SDK versions. Where the driver sources are stored is then not that important - just keeping releases under control would be. ]
The Designer stuff is a gotta have and really its not that hard, especially if your not building everything from scratch. I slogged out more then a half a dozen modules Saturday night while I was winding down for bed. Tonight I pretty much finished up the DFRobot Player module until I couldn’t find a 1GB or less Micro SD card to test it with, but tomorrow I’ll shoot some pictures of the module and finish up the designer part of the driver and then its just a matter of testing and maintenance forward will be easy. When the module driver has been built once, its pretty easy to keep it up as the designer stuff doesn’t change.
Anyone got some suggestions as to what modules they would like to see updated to 4.3 next?
Right now I’m leaning toward putting this stuff up on CodePlex so I can put up the source and the installer exe in the directory structure I want.