... | ... | @@ -6,7 +6,7 @@ |
|
|
|
|
|
Kea 1.6.0 and earlier releases were going out roughly once every 6 months. Initially the date was roughly repetitive, but with increased number of customer requests, it was more and more difficult to deliver planned features on time and not neglect requests for support. This resulted with the releases not being that predictable.
|
|
|
|
|
|
Every time we did a release (1.4.0, 1.5.0, etc), it was always a feature release introducing new features. Versions ending with something else than 0 were very sporadic and done only when specific circumstances required us to release them.
|
|
|
Every time we did a release (1.4.0, 1.5.0, etc), it was always a feature release introducing new features. Versions ending with something else than 0 were very sporadic and done only when specific circumstances required us to release them.
|
|
|
|
|
|
For every feature release there was at least one beta release (done a month in advance). After beta was out, there was a memorandum on adding new features and only bugfixes and minor improvements could be committed between beta and final releases. In recent betas, we often slipped some features in. We very rarely received any feedback for betas, and even when we did, it was usually too late to do anything about it.
|
|
|
|
... | ... | @@ -56,7 +56,7 @@ For stable releases, there will be a branch (e.g. v1_6_0). If we do v1_6_1, it w |
|
|
|
|
|
## Challenges/Tasks needed
|
|
|
|
|
|
* [x] There will be more releases. On the other hand, the burden of handling patches is expected to be decreased. Instead of going through patches, the answer will often be: please upgrade to x.y.z.
|
|
|
* [x] There will be more releases. On the other hand, the burden of handling patches is expected to be decreased. Instead of going through patches, the answer will often be: please upgrade to x.y.z.
|
|
|
* [ ] Need to clarify our EOL policy: we will support last two major branches. Once 1.6.0 is out, we'll drop support for 1.4.x shortly afterwards.
|
|
|
* [ ] Need to come up with a good naming for the releases: _development_, _preview_ or _engineering drop_ are some candidates. I don't like _unstable_, because they'll not really be unstable (they'll go through the same QA process as every other release), more like some of the new features will be a work in progress.
|
|
|
* [x] we will stop using tags for purpose other than releases.
|
... | ... | @@ -67,10 +67,10 @@ automating release process will be a challenge for example, before release I'm d |
|
|
- check perflab for results
|
|
|
- check jenkins to make sure everything is ok
|
|
|
- check is there are no critical tickets left to do
|
|
|
- check known issues list if everything that was listed in previous version was fixed
|
|
|
- check known issues list if everything that was listed in previous version was fixed
|
|
|
- check lib versioning
|
|
|
- check hook version
|
|
|
it will probably had to be done before each release.
|
|
|
it will probably had to be done before each release.
|
|
|
|
|
|
Also we need there are some documentation checks:
|
|
|
- update supported platforms if needed
|
... | ... | @@ -87,4 +87,4 @@ Automated steps at the moment: |
|
|
Things I'd like to see are:
|
|
|
- [ ] get rid of copy right dates from files... bind does that, why can't we? See #391 - planned in 1.7
|
|
|
- [x] keep list of 3rd party software needed in ONE place (partially https://gitlab.isc.org/isc-projects/kea/issues/347)
|
|
|
- [ ] keep installation instructions in ONE place (not in INSTALL, Users Guide, KB...) |
|
|
\ No newline at end of file |
|
|
- [ ] keep installation instructions in ONE place (not in INSTALL, Users Guide, KB...) |