Master is branched into an official stable release named "v2.0" on, next morning you can download "v2.0-20180508". Master is updated on 2018-04.07 with new code, next morning you will be able to download the release "master-20180408" (current tag name for that release is "mega"). To explain this we provide these examples: So the master branch will always have many more releases than the frozen stable releases which will only have one (until a bug fix release is generated). Nightly builds are always generated if something has been updated in the source code. These will have much less plugins by default since they are not needed for these units, this makes flashing units with less than 1MB possible. Knox which will become v2.1.0 - focusing on securityĬarta which will become v2.2.0 - focusing on communication unit2unit and unit2controllerĪs of release mega we will also try to get more hardware specific builds for especially Sonoff units. Mega which will become v2.0.0 - getting more plugins and much more features (thus the tag "mega" which indicates that a bigger memory is needed for the generic FW) A preliminary list for the future focus areas are: Stable releases will have a version number similar to "v2.0.0" but focusing areas for development will have short tag names such as "Mega" which indicate the focus for the next big release. L: legacy freeze (R147 code) D: development (cutting edge) FF: feature freeze R: release of new stable Branch this table is outdated and needs to be updated. Please observe that this table is not the road map, just an example to explain the different names and numbers. Below you will find a explanation on how we intend to do the branching and releases of future firmware versions.
New features, and experimental stuff, is poured into the development branch (master). New features that cannot wait until next v2.1 release will be branched into v2.0.1 (this might not happen if no ground breaking feature is added). Once we have reached all the milestones for version 2.0.0 we will freeze the source from that point and fork that into a branch called v2.0, only bug fixes is going into that branch.
STANDARD ESP8266 FIRMWARE VERSION CODE
The legacy branch is the archive, a point zero if you like, which is the exact copy of the source code before we started the re-write. The current master branch on GitHub is where all the development goes into. We later switched this to the correct name. So after a somewhat bad decision in the early days of the re-write project we started to call the development branch "Mega" instead of the more accepted name "Master". This is a bit tight for our goal to add many more useful features to the firmware. Prior to mega we allowed smaller mem-sizes (sub-megabyte, aka 512kb) for the official releases. We started to call the extensive re-write of the source code "Mega", which is an hint of the size needed for the next big stable release.
Well, this is a short version of our naming convention here at the ESP Easy initiative. Do you want to help us with that? Read more in this announcement here. We have some big (even huge) features that we want to give you but time is scarce and we need to quit our daytime jobs. The plan is to make this an awesome "operating system" for IoT. There are so called "nightly builds" which can be found on the Releases page. Configuration of the ESP Easy is entirely web based, so once you've got the firmware loaded, you don't need any other tool besides a common web browser.ĮSP Easy also offers limited "low level" actuator functions but due to system instability, this could be less useful in real life applications.ĮSP Easy is under continuous development as can be seen on the GitHub page and on the Forum. The ESP Easy firmware can be used to turn the ESP module into an easy multifunction sensor device for Home Automation solutions like Domoticz.
0 kommentar(er)
