Lines Matching +full:in +full:- +full:development
10 The stable releases go on to a branch like v4.0-stable as described below, over
12 backported from the development branch. So you should not consume tags like
13 v4.0.0 but build into your planning that you will need to follow v4.0-stable in
24 ## Development section in lws release policy
27 subject to history rewrites, patches moving about and being squashed etc. In
29 runtime tests, so if it is passing CI as it usually is then it's probably in
30 usable shape. See "Why no history on development" below for why it's managed like
33 
42 $ git fetch https://libwebsockets.org/repo/libwebsockets +main:m && git reset --hard m
45 This fetches current remote development branch into local branch `m`, and then forces your
46 local checkout to exactly match `m`. This replaces your checked-out tree
48 to pop them before updating your basis against lws development.
52 Master is very useful for coordinating development, and integrating WIP,
54 more desirable than the latest development work.
56 Periodically, when development seems in good shape and various new developments seem
57 to be working, it's copied out into a versioned stable branch, like `v4.0-stable`.
59 
63 (At that time, development's logical version is set to "...99", eg, `v4.0.99` so
64 version comparisons show that development version is "later" than any other
70 Development continues, and as part of that usually bugs are reported and / or
71 fixes found that may apply not just to current development, but the version of
72 the development branch that was copied to form the last -stable branch.
74 In that case, the patch may be backported to the last stable branch to also fix
75 the bug there. In the case of refactors or major internal improvements, these
78 This applies only to fixes and public API-neutral internal changes to lws... if
86 
88 If there is something you need in a later lws version that is not backported,
96 Periodically fix patches pile up on the -stable branch and are tagged out as
100 
109 
111 ## Why no history on the development branch
116 dispense with feature branches during development and enables tracking multiple
117 in-progress patches in-tree by updating them in place. If this doesn't make
119 just sit back and enjoy the clean, rapid development results.
122 with a history, like a one-way pile of patches on top of the original release. If
123 CI shows something is messed up with the latest patch, I will edit it in-place if
124 it has only been out for a few hours, but there is no re-ordering or other history