Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

start development towards 7.0.4 #10342

Closed
wants to merge 1 commit into from
Closed

start development towards 7.0.4 #10342

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion configure.ac
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
AC_INIT([suricata],[7.0.3])
AC_INIT([suricata],[7.0.4-dev])
m4_ifndef([AM_SILENT_RULES], [m4_define([AM_SILENT_RULES],[])])AM_SILENT_RULES([yes])
AC_CONFIG_HEADERS([src/autoconf.h])
AC_CONFIG_SRCDIR([src/suricata.c])
Expand Down
4 changes: 2 additions & 2 deletions requirements.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,5 +3,5 @@
# Format:
#
# name {repo} {branch|tag}
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why set this to master? It was 1.3.0 before the release

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 libhtp goes w a dev branch of suricata, latest version of a respective suricata-update branch should go as well.
  • Given that we don't have a 1.3.x branch, current master of suricata-update represents the latest state that we use and bundle with suricata's 7.0.x.
  • Similarly, for suricata 6.0.x, we use the branch 1.2.x of suricata-update as that reflects the latest state of what should be used and bundled.
  • Please note that for now, in suricata-update,
    branch master == tag 1.3.0 and,
    branch master-1.2.x == tag 1.2.8

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thanks for clearing that up.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Loading