search

simsong / bulk_extractor

This is the development tree. Production downloads are at:
https://github.com/simsong/bulk_extractor/releases
Other
1.08k stars 185 forks source link

Updated README #148

Closed joachimmetz closed 4 years ago

simsong commented 4 years ago

FYI — I'm doing most of the 2.0 dev over in: https://github.com/simsong/bulk_extractor/tree/release-2.0-dev

joachimmetz commented 4 years ago

ack thx, let me know which branch you would like PRs with fixes against.

simsong commented 4 years ago

ack thx, let me know which branch you would like PRs with fixes against.

I'm putting together a roadmap. Now that I have unit-tests for dfxml, I'm creating unit-tests for be13_api. (I see no reason to rev the API for BE2.0). We should discuss what to do about the master branch vs. the release-2.0-dev. My feeling is to have a release-1.5 branch which is a branch of master and then to freeze master until we have a functional 2.0. If that sounds good to you, I'll create a formal roadmap with check boxes and you and I can fill it out.

joachimmetz commented 4 years ago

If that sounds good to you, I'll create a formal roadmap with check boxes and you and I can fill it out.

Excellent, a formal or rough outline, since 1.5.6 or 1.6.0 or 2.0 does not tell me anything without a corresponding explanation ;)

My feeling is to have a release-1.5 branch which is a branch of master and then to freeze master until we have a functional 2.0.

TL;DR my preference is for the solution with the least administrative overhead.

Most people want a source distribution package (result of make dist) anyway instead of a git clone.

Hence I would do a master branch with a current release (1.6.1 since there has been already been a 1.6.0 tag) first.

Having a separate dev branch SGTM (sounds good to me) in principle but note the value of such a branch will depend on how much back porting to master you are planning to do and time between releases. I've seen projects use very elaborate branching schemas without obvious benefits and adding more confusion instead. So I'm also fine continuing with master (dev) and feature branches for PRs (within this repo or on a fork).

simsong commented 4 years ago

Release 1.6.0 and 1.6.1 were source-code only releases. They were never packaged and put onto the download server. I would like a 'git clone' to produce a compilable, runable system from the 'master' branch. I believe that this is currently the case for 'master'.

I want to do commits to github as a backup, and I don't want to break master. So I think that it makes sense to commit to the release-2.0-dev branch until it is a working copy of bulk_extractor, at which point I'll make it the master branch. Sound good?

joachimmetz commented 4 years ago

I want to do commits to github as a backup, and I don't want to break master.

The idea behind using feature branches and PRs, is that all the CI tests run before code is merged. You can even use a code review process to have someone have a second look at the code. So you never have to break master either.

However in both workflows master can still break, e.g. if something not covered by tests or change to the build environment like a new compiler. The downside of multiple branches is then that you now need to patch all branches.

So I think that it makes sense to commit to the release-2.0-dev branch until it is a working copy of bulk_extractor, at which point I'll make it the master branch.

SGTM, merging branches should be very straightforward is the master has been frozen.

I would still recommend using release tags (source code only or not), since that is how github knows which commit is linked to other release files. And a specific tag can be cloned as well.

Also "source code only" is a bit misleading here, since the github functionality does not provide a real source distribution package (like make dist does) but only a tar.gz/zip of the contents of the repo.

simsong commented 4 years ago

We will still use release tags. My understanding is that github has downloads functionality as well from the github.io pages. In the meantime, I'm still working on getting dfxml and be13_api ported to C++14. It's been a lot of work! But it's been a lot of fun. Too much fun.