-
-
Notifications
You must be signed in to change notification settings - Fork 103
Bug or Feature
This section is meant to clarify when we consider a bug 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. For users: Please have a look on our [Bug Report writing Guidelines] (Bug-Report-writing-Guidelines). For developers: 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. For developers: 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. For users: Please have a look on our [Feature Request writing Guidelines] (Feature-Request-writing-Guidelines). For developers: 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.
- MINOR versions will contain enhancements or small improvements and are considered to be backwards-compatible to the previous version of the same release line.
- PATCH versions contain only backwards-compatible bug fixes. Upgrading to a new release version is considered easy and safe.
- 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/
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.:
| Stable | Unstable | Comment |
|---|---|---|
| 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 |