We're always updating our Road Maps, so please expect that they will change without much notice! We add (and drop) features for three reasons:
- We have a new feature idea that's simply more interesting to you than an existing feature on the Road Map
- We decide it makes sense to move a bucket of features into an upgrade or even a separate product (e.g.. Network CRM)
- A feature is very hard or time-consuming to implement, and needs to be deferred (or simply cancelled)
The Road Map shown here is our best current idea of features that will be in the next versions of our products. Please read it with the understanding that it is, at best, mostly accurate.
Network CRM Releases
As our customer base has grown to include some of today's largest and most respected organizations, our processes have matured to support organizations of all sizes.
Network CRM Version Status
|3.x||3.4.1||Prior Major Release||n/a|
|2.x||2.3||Deprecated Release||Released February 1, 2009|
|1.x||1.1.1||Deprecated Release||Released August 28, 2007|
The following guidelines describe our release strategy to keep developers informed on API changes that may occur from one release to the next.
What Network CRM version are you on?
While all of us at Network Gate drive to move the framework forward technologically, we understand the importance of defining a stable and dependable API for our developer community. Network CRM versions are labelled in order to move the framework along a well defined path to deliver bug fixes, new features and enhancements in a timely fashion. To balance these needs, Network CRM follows the principle of major.minor.patch version numbering whereby versions are denoted using a standard triplet of integers: major . minor . patch
Each version represents improvements to prior releases in the form of bug fixes, enhancements and new features. The purpose of labelling versions this way is to communicate the kind of change that occurs between releases and some indication of the effort required to upgrade to a newer release.
Major Versions are large-scale upgrades of the API which may introduce a change in prior behaviour, remove deprecated properties from a prior major version, or contain fixes and enhancements that could not be accommodated without breaking backward compatibility. Major releases may introduce new classes, new properties, and may deprecate existing classes or properties. Major releases have the minor and patch numbers set to 0. A Major version will be released approximately annually.
Minor Versions will maintain compatibility with older minor versions. Some classes or properties may be deprecated, however the earliest they will be removed completely is the next Major release. Minor releases have the patch number set to 0. Minor versions will be released approximately every 4 months.
A patch version is the most up to date, stable version available. Changes in Patch versions are backwards compatible. These versions are a conservative incremental improvement that includes bug fixes, enhancements and new features and is absolutely backward compatible with previous PATCH releases of the same MINOR release. Changes to the API, to the signatures of public functions, or to the interpretation of function parameters will not change. Patch releases increment the patch number compared to the most recent patch release. Patch versions will be made available approximately monthly to Support Subscribers.
It is important to note that any release prior to a x.0 release is not subject to the guidelines described in this document. The version number may also be followed by an optional status e.g. 3.0-RC1.1. The optional status is an indicator of the release status, e.g. -alpha2, -m2, -rc1, etc. Generally, the status indicator is only used for major releases, e.g. 1.0.0-rc1 but is available for any release at the release manager's discretion. Before a x.0 release (pre-release, release candidate (RC), alpha, beta, etc.), the API can and will be changing freely, without regard to the restrictions detailed by this document.
Before a new major release, release candidate (RC) packages are made available so that users can test them against their own code. There will be one or more release candidates given the version major.minor.0 RC, where the major and minor version numbers identify the upcoming release and RC1 identifies the first candidate release, RC2 the second, and so on. A release candidate does not guarantee backward compatibility with new API features introduced by any previous RC of the same upcoming version. A major version RC can change/remove API features introduced in a previous RC for the same major version.
We define "compatible" to mean that the API will remain unchanged. Generally, the objective is to maintain backward compatibility for minor releases and patch releases but major releases may not be completely backward compatible. Class properties may be marked deprecated with the intent to remove them in a future Major Version.
Network Gate Version Compatibility
|Prior version||New version||Compatible?|
|4.0.1||4.0.2||Yes, compatibility across patch versions is guaranteed.|
|4.0.1||4.1.0||Yes, compatibility with later minor versions is guaranteed.|
|3.2.1||4.0.0||No, compatibility with different major versions is not guaranteed.|
|4.0.0||3.4.0||No, compatibility with different major versions is not guaranteed.|
Get Subversion Access
The development team continuously maintains the code and API documentation, adding features and addressing issues. Live updates to the code are maintained in a subversion repository which is available to Support Subscribers.
The subversion repository enables Support Subscribers to:
- keep local copies of the source up to date automatically
- continuously get the latest updates to the API documentation
- get a change history of files, diffs between arbitrary versions, etc.
- constantly keep abreast of the latest enhancements and fixes
- get advance preview of new examples as they are added
There are two branches maintained within the repository. There is one branch for the latest major version, and another branch for the prior major version. Each branch accommodates new features and bug fixes in a minimally disruptive way if at all possible.
The following are the stages of the development of Network Gate products:
- Development. Under development and has not been made available to the general public.
- Beta, Milestone (M), and Release Candidate (RC). Released to the public but is not deemed to be stable for production.
- Official Release. Released to the public and is deemed to be stable. At this stage the software is the recommended version for production systems.
- Prior Major Release. Software that was deemed as an official release in the past, but for which a newer major official release has become available. Prior Major releases are eligible for "legacy" support, but Network Gate encourages an upgrade to the latest Major release as soon as possible.
- Deprecated Release. Software that has been replaced by at least two new major release. Deprecated releases are not supported in any way by Network Gate and may no longer be available for download.
The following table details the various download, upgrade, and support options that are available for each of the above mentioned types of release.
Network Gate Product Lifecycle
|Milestone or Pre-Release||Official Major Release||Prior Major Release||Deprecated Release|
|Ongoing Support Available||No||Yes||Yes||Forums only|
|Recommended Usage||Testing by developers, contributors, and others wishing to use the latest version of Network Gate||General production use||Ext JS recommends updating to the most recently available Major release||Anyone running a "deprecated release" should immediately upgrade|
|Associated Risks||Beta quality software may have critical bugs, patches should be expected||Higher support costs, lack of ongoing development, minimal bug-fix patches, version is closer to being deprecated.||Lack of support, lack of ongoing development, downloads may not be available, no security patches, no bug-fix patches, potential loss of some or all upgrade paths to present releases.|
|Documentation Availability||actively maintained||yes||minimally maintained||not maintained and may not be available on-line|
In addition to the files included within the Network Gate framework, Network Gate also ships with several types of examples to illustrate and inspire how you might leverage the framework.
Network Gate ships with a comprehensive set of examples which are intended to demonstrate how to use various portions of the framework. Some examples may include customizations that are intended to illustrate a particular technique or inspire a developer.
ux - The "User Extension" namespace
The "ux" namespace contains custom code usually in the form of Classes. Some characteristics to note:
- ux's typically extend/modify existing Classes or provide new features.
- various ux implementations may not be compatible with each other.
- inclusion of an ux may be discontinued at a Major release.
Some classes and examples may be introduced as "experimental". Experimental items have not been finalized and are subject to change.