Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Bug or Feature
This section is meant to clarify when we consider an issue reported as a defect, enhancement or a feature.
Bugs, defects or issues, are things that need to be fixed urgently (ideally, in the next release) and do impair the functionality of the software.
Please have a look on our Bug Report writing Guidelines.
Please commit a bug fix for the current stable and the unstable version as two separate pull requests.
Enhancements, improvements are things which are implemented for the current stable version and improve an already implemented feature of deegree.
Please commit an enhancement for the current stable and the unstable version as two separate pull requests.
Feature requests are things that need to be added at some point in the future and will add new functionality to the software.
Please have a look on our Feature Request writing Guidelines.
Please commit a new feature for the unstable version only! The TMC will not except new features for the current stable version! Please read the following paragraph about semantic versioning which explains why.
Each release of deegree has a version number. The version number has the pattern 3.4.0 or in general MAJOR.MINOR.PATCH. This has some implications.
- MAJOR versions provides new features but can also drop features. Major versions can result in changes to the deegree workspace configuration. An upgrade of configuration files may be needed!
- MINOR versions will contain enhancements or small improvements and are considered to be backwards-compatible to the previous version of the same release line. Configuration files may include backward compatible changes such as optional attributes or elements.
- PATCH versions contain only backwards-compatible bug fixes. Upgrading to a new release version is considered easy and safe. No changes to the deegree configuration files needed.
- MAJOR versions allow to make incompatible API changes. Changing the signature of a public method, remove or move a public class or interface to a different package. Creating new packages and types are considered as API changes too. As well as changes to the configuration files!
- MINOR versions allow to add functionality in a backwards-compatible manner by adding a protected or private method.
- PATCH versions allow to make backwards-compatible bug fixes by changing a method implementation block only! You can add private methods only!
Read more about semantic versioning here: http://semver.org/
Stable vs unstable version
A stable version is the current line of releases which has been tested and is virtually "bug free".
An unstable version has not been tested (only automatic unit and integration tests) and is still under development. A unstable version replaces the previous version when it is finally released. It also indicates the public announcement of the launch of any new version (stable). Where the term 'release' indicates a particular version of a deegree web services.
The following example shows the lifecycle. Let's assume that we have already released 3.3.0 and move on towards 4.0.:
|3.3.0||3.4-pre1||With releasing 3.3.0 the trunk is set to 3.4|
|3.3.1||3.4-pre2||bug fix release for 3.3 line|
|3.3.2||3.4-pre3||bug fix release for 3.3 line|
|3.3.3||3.4-pre4||bug fix release for 3.3 line|
|...||...||several bug fixes for 3.3 line|
|3.3.6||3.4-pre6||bug fix release for 3.3 line|
|3.3.7||3.4-RC||last bug fix release for 3.3 line, 3.4 release candidate|
|3.4.0||3.5-pre1||3.3 line ends, 3.4 line is now stable, starting new unstable 3.5 line|
|...||...||several bug fixes for 3.4 line|
|3.4.7||3.5-RC||last bug fix release for 3.4 line, 3.5 release candidate|
|3.5.0||4.0-pre1||3.4 line ends, 3.5 line is now stable, starting new unstable 4.0 line, which contains new features|
|4.0.0||4.1-pre1||3.5 line ends, 4.0 line is now stable, starting new unstable 4.1 line for bug fixes and enhancements|