start development towards 7.0.4 #10342
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main-7.0.x #10342 +/- ##
==============================================
- Coverage 82.25% 82.25% -0.01%
==============================================
Files 975 975
Lines 274915 274915
==============================================
- Hits 226128 226125 -3
- Misses 48787 48790 +3
Flags with carried forward coverage won't be shown. Click here to find out more. |
| libhtp https://github.com/OISF/libhtp 0.5.46 | ||
| suricata-update https://github.com/OISF/suricata-update 1.3.0 | ||
| libhtp https://github.com/OISF/libhtp 0.5.x | ||
| suricata-update https://github.com/OISF/suricata-update master |
There was a problem hiding this comment.
why set this to master? It was 1.3.0 before the release
There was a problem hiding this comment.
I think this is what Jason and I agreed on. But, I'll let him answer in case I misunderstood.
- The thought is that just like the latest version of
libhtpgoes w a dev branch ofsuricata, latest version of a respectivesuricata-updatebranch should go as well. - Given that we don't have a
1.3.xbranch, currentmasterofsuricata-updaterepresents the latest state that we use and bundle with suricata's7.0.x. - Similarly, for suricata
6.0.x, we use the branch1.2.xofsuricata-updateas that reflects the latest state of what should be used and bundled. - Please note that for now, in
suricata-update,
branchmaster== tag1.3.0and,
branchmaster-1.2.x== tag1.2.8
There was a problem hiding this comment.
Ok, thanks for clearing that up.
There was a problem hiding this comment.
I missed this, only noticed because I was looking for the commit ID for a forward port :)
This works as long as we pin the versions and commit before we tag Suricata.
So will the dev tools take care of this? For example, when I go and checkout the tag suricata-7.0.4 (after its released of course), I should see specific versions in this file.
There was a problem hiding this comment.
yes, we already do that :)
Prep stage: the requirements.txt gets an update of specific libhtp and suricata-update version that needs to be bundled in the release. e.g. be68bbc#diff-4d7c51b1efe9043e44439a949dfd92e5827321b34082903477fd04876edb7552
Post release stage: the requirements.txt go back to the libhtp and suricata-update branches corresponding to the respective suricata version. e.g. this PR
|
Can you combine this with CI backports just merged in master? |
No description provided.