Net2MAX Releases
From Net2MAX
|
1. Net2MAX Introduction | |
Contents |
1 Introduction
In order to take advantage of continuous improvements in new technologies and applications, Net2MAX provides constant updates to the system based on feedback from users.
Net2MAX has an unique way of releasing new features and bug fixes to cover the full range of users, there are ecosystems for the adventurous types who wants to try the latest of everything to the risk adverse types who still wants to be progressive.
2 Ecosystem Types
There are 4 types of ecosystems with different functionality and stability goals.
2.1 Research Ecosystem
The Research Ecosystem (beta.net2max.com) is a free ecosystem where engineers from Net2MAX Labs can work with users from different Net2MAX ecosystems around the world to create new releases of Net2MAX.
There is only one Research Ecosystem worldwide and membership is by invitation only.
Users who make contributions to Net2MAX (give suggestions, submit software, supply hardware, perform testing, provide support, develop applications, introduce technology etc.) are given accounts in the Research Ecosystem so they can help shape Net2MAX at its earliest stage.
The research ecosystem is updated every day with new features and bug fixes.
Depending on their interests and their areas of expertise, users might belong to one or more communities within the Research Ecosystem.
- Some research communities are closed to certain people only (e.g. certain government related projects), but most are opened for anyone within the Research Ecosystem to join.
- Most research communities require signing of confidential agreements, but some have no such requirement.
- Some research communities provide software and hardware "toys" for free to their members, but most rely on using the member's existing equipment and environment to test for interoperability.
2.2 Development Ecosystem
The Development Ecosystem (net2max.com) is a conditional ecosystem that has real customers. It is used to perform rapid continuous development on paying members.
The Development Ecosystem is currently is based in Australia with members, communities and neighbourhoods worldwide. It is governed by Australian law, the currency is based on Australian dollars and the main language is English.
There is only one Development Ecosystem and membership is opened to anyone with interest in furthering the development of Net2MAX. It is available on the condition that we reserve the right to stop adding new members or cancel existing membership at our discretion.
The Development Ecosystem is for adventurous users who wants to experience the latest Net2MAX advances at a rapid pace. It is also a great place for Net2MAX consulting, software and hardware partners to experiment with their products and services.
Net2MAX technologies and applications that
- have reached a certain stage of maturity
- can be released to the public
- are of benefit to the members
are transferred from the Research Ecosystem into the Development Ecosystem in form of weekly updates.
Updates normally take place on Wednesday although it can occur on other days as required. The lack of updates for a week provides a period of stability for integrated testing and documentation before more changes is made to the system.
Note:
- For high security use Production Ecosystems ONLY e.g. no audit by external security organisation performed with Development Ecosystem
- For high performance use Production or Staging Ecosystems e.g. all Information Hosts of the Development Ecosystem are located in Australia
- For high compatibility use Production or Staging Ecosystems e.g. only web browser supported fully is Microsoft Internet Explorer in the Development Ecosystem
2.3 Staging Ecosystems
Features that have reached a certain stage of maturity are transferred from Development Ecosystem to Staging Ecosystems in each country on a monthly basis for:
- exposure to higher volume usage and more application variations.
- fine tuning of localisation efforts in the target country.
Net2MAX Ecosystems in each country take the localised version in the Staging Ecosystem to create their own customised version for their members under their own Production Ecosystem.
Every year there are 8 monthly releases to Staging Ecosystems:
- January (s1)
- February (s2)
- April (s4)
- May (s5)
- July (s7)
- August (s8)
- October (s10)
- November (s11)
For Staging Ecosystems, there is no normal releases (feature freeze is enforced) in March, June, September and December to allow more time for debugging and tuning in preparation for the quarterly release into the Production Ecosystems.
To separate different staging releases year from year, the year is added in front. For example release 2010s7 means the July release of the staging ecosystem in year 2010.
When there are urgent bug fixes that cannot wait until the next monthly release, they are applied to the Staging Ecosystem with the release number increasing by a sub-number. For example, a the first bug fix release to apply to the November release is s11.1 and the second bug fix release to apply to the November release is s11.2. There is NO normal monthly release in December, so all the bug fixes releases applied in December will be on top of the November release number e.g. s11.3, even though the third bug fix release is made in December.
Note:
- For high security use Production Ecosystems ONLY. Although audit by external security organisation are performed on the Staging Ecosystem, there is no guarantee at any point in time that Staging Ecosystem you are using has passed the all the audits.
2.4 Production Ecosystems
Features that have being running stable in Staging Ecosystems are transferred Production Ecosystems on a quarterly basis. They will have to get past independent 3rd party security audit before being released into Production Ecosystem.
Every year, Production Ecosystems have 4 quarterly releases:
- January (p1)
- April (p4)
- July (p7)
- October (p10)
Production Ecosystems are security audited copies of stable Staging Ecosystems, made 4 times a year to take advantage of the testing performed in the Staging Ecosystems, to achieve a reliable and secure operating environment.
- The January production release (p1) is the same as the last bug fix release of the November staging release (e.g. s11.4).
- The April production release (p4) is the same as the latest bug fix release of the February staging release (e.g. s2.3).
- The July production release (p7) is the same as the latest bug fix release of the May staging release (e.g. s5.8).
- The October production release (p10) is the same as the latest bug fix release of the August staging release (e.g. s8.2).
When there are urgent bug fixes that cannot wait until the next quarterly release, they are applied to the Production Ecosystem with the release number increasing by a sub-number. For example, a the first bug fix release to apply to the January release is p1.1 and the second bug fix release to apply to the January release is p1.2. There is NO normal quarterly release in February and March, so all the bug fixes releases applied in February and March will be on top of the January release number e.g. p1.3, even though the third bug fix release is made in February.
To separate different production releases year from year, the year is added in front. For example 2010p7 means the July release of the production ecosystem in year 2010.
3 Automatic Updates
Automatic updates allow the Net2MAX infrastructure to receive continuous improvements and fixes in an enforced manner.
3.1 Normal Releases
Normal Releases take place every month for staging ecosystems and every quarter for production ecosystems.
Infrastructure operators are given 7 days notice to pull the new normal release onto their infrastructure, after 7 days if they have not applied the normal release themselves AND they have not replied back to specifically block the automatic update, then the normal release will be automatically applied to their infrastructure after the 7 days.
To remain within an official Ecosystem, normal releases cannot be blocked by the Infrastructure Provider for more than 2 consecutive times.
3.2 Bug Fix Releases
Urgent Bug Fixes (normally security related) are applied in between the monthly releases for staging ecosystems and between quarterly releases for production ecosystems.
Infrastructure operators are given 3 days notice to pull the new bug fix release onto their infrastructure, after 3 days if they have not applied the bug fix release themselves AND they have not replied back to specifically block the automatic update, then the bug fix release will be automatically applied to their infrastructure after the 3 days.
To remain within an official Ecosystem, bug fix releases cannot be blocked by the Infrastructure Provider for more than 2 consecutive times.
4 Time Frames
Times listed below are estimations only and subject to change at any time without notice.
4.1 Development Ecosystem
Existing Net2MAX 2.0 members are expected to be converted over to Net2MAX 3.0 in August 2009. Members are expected to be able to form their own Net2MAX Communities and provide their own Net2MAX Applications by December 2009.
|
Estimated Development Milestones
|
Members are expected to be able to provide Net2MAX Infrastructure themselves from middle of 2010.
|
Estimated Development Milestones
|
4.2 Staging Ecosystem
Staging Ecosystems with more stability than the Development Ecosystem are expected to be rolled out in the first half of 2010.
|
Estimated Staging Milestones
|
4.3 Production Ecosystem
Production Ecosystems with more stability and localisation than the Staging Ecosystem are expected to be rolled out in the second half of 2010.
|
Estimated Production Milestones
|
