Last year AREDN moved away from a formal set of beta test scripts and dedicated testers to a more agile beta general-release model.  Users were eager to get their hands on features they requested months earlier and help us test in preparation for a production release.   While we have been happy with the results, we have noticed that features that take a long time to develop only see the light of day months after development.  We have no easy way to learn from them before beta release.  Today, this is changing.
 
We are going to give anyone who wants it, access to the AREDN development branch builds, which includes the latest features we are developing… even before we are done with them!
 
We have been criticized by some for putting out too many releases.  Our philosophy, which does differ from some other organizations, is very much aligned to the vast majority of open source projects in the industry.  We are completely committed to following this successful model. It is an approach that is more suitable to our nature characterized by: dynamic requirements, a small number of developers, a culture that readily responds to change, and a user community of hams comprised of a highly technical subset who are mature enough to distinguish bleeding-edge from production-ready software.
 
AREDN uses a continuous integration build server (CircleCI) which is an automated process that runs scripts at night on our servers and compiles snapshots of work committed on that day.  Commits don’t occur every day, so you won’t find a new build every day.  CircleCI also reports which packages fail to build, so that developers get feedback on possible errors.  Accompanying these builds is a running change list so you can tell if a specific ticket has been addressed in a given build.
 
The AREDN development branch contains bleeding edge source code which can only be described as experimental code that is under active development and should not be used for production environments. These images may also support additional hardware, however, it is experimental, considered unstable, sometimes won't even compile, and may in fact require you to TFTP or force a reload using a TTL to serial port converter.
 
We are doing this so we can get early feedback on features and functions.  It’s a lot faster/cheaper to make changes to these when we’re developing them than after they're in a production release.  Remember, this is not for the beginner, and we do not intend to provide a lot of support for getting devices out of a jam… we expect those who load these builds to already have the skills and tools to “return these devices from the edge”.
 
We appreciate those who are willing to look at these and provide us that feedback. .
 
The nightly builds can be found at: https://www.arednmesh.org/content/nightly-builds
 
The CHANGELOG file is here.