You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The version history is motivated by https://semver.org/ and https://keepachangelog.com/en/1.0.0/ .
6
+
7
+
NOTE: This project went from non-standard versioning to semver at some point.
8
+
9
+
## Structure
10
+
11
+
Types of changes that can be seen in the changelog
12
+
13
+
```
14
+
Added: for new features/functionality.
15
+
Changed: for changes in existing features/functionality.
16
+
Deprecated: for soon-to-be removed features. Removed in the
17
+
Removed: for now removed features.
18
+
Fixed: for any bug fixes.
19
+
Security: in case of vulnerabilities.
20
+
```
21
+
22
+
## How deprecation of functionality is handled?
23
+
24
+
tl;dr 1 minor release stating that the functionality is going to be deprecated. Then in the next major - removed.
25
+
26
+
```
27
+
Deprecating existing functionality is a normal part of software development and
28
+
is often required to make forward progress.
29
+
30
+
When you deprecate part of your public API, you should do two things:
31
+
32
+
(1) update your documentation to let users know about the change,
33
+
(2) issue a new minor release with the deprecation in place.
34
+
Before you completely remove the functionality in a new major
35
+
release there should be at least one minor release
36
+
that contains the deprecation so that users can smoothly transition to the new API
37
+
```
38
+
39
+
As per https://semver.org/ .
40
+
41
+
As per rule-of-thumb, moving the project forward is very important,
42
+
but providing stability is the most important thing to anyone using `vaulted`.
43
+
44
+
Introducing breaking changes under a feature flag can be ok in some cases where new functionality needs user feedback before being introduced in next major release.
0 commit comments