Issue integration to the code and Versioning Standard

[H4ppy-04]

It seems to be the method of integration is rebasing as of now, is this to be the default practice?

[initd1]

Yes. My idea for dealing with branches is as follows:

1. Feature/Enhancement/Bug branches are created per issue which are then merged to the main branch
2. The main branch remains a protected branch, and requires approval of PR's from Feature/Enhancement/Bug branches before being merged into the main branch
3. When a good number of features are implemented and merged into main, a separate release branch is created from main
4. The release branch follows the Semantic Versioning naming convention https://semver.org/

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.6.

5. A tag by the same name will be created post release
6. The release branch will be locked and serve as the Last Known Good for any future work

[initd1]

I am happy to hear your thoughts on this, and feel free to share your suggestions.

[H4ppy-04]

i completely agree, myself being a religious semver person myself. I assume you also mean incrementing patches upon bugfixes? Also I have a question: are any branches to be deleted at any point in time?

[H4ppy-04]

In addition to this, I've also drafted the following contributing file:

Contributing to HackAlert

Thank you for your interest in contributing to HackAlert! We appreciate your help in making our product better and more secure.

About HackAlert

HackAlert is a tool that scans the internet for your online persona, including financial, social, and personal accounts, to detect data breaches or hacks. With real-time notifications via text or email, you can take action before it's too late. Stay safe and secure with HackAlert.

Technical Development Guidelines

Branch Naming Conventions

When creating branches, please follow these naming conventions:

• feature/<feature-name> for new features
• enhancement/<enhancement-name> for improvements to existing features
• bug/<bug-name> for bug fixes

Git Branch Management

1. Create a new branch for each issue and work on the feature/bug in that branch.
2. Merge your completed feature/bug branch into the main branch via a pull request.
3. The main branch is a protected branch and requires approval of pull requests from feature/bug branches before being merged.
4. When a good number of features are implemented and merged into main, a separate release branch is created from main.
5. The release branch follows the Semantic Versioning naming convention https://semver.org/. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.6.
6. A tag by the same name will be created post-release.
7. The release branch will be locked and serve as the Last Known Good for any future work.

Environment Set-up

To set up your development environment, please follow these steps:

1. Clone the GitHub repository

git clone https://github.com/initd1/HackAlert.git

2. Install Python and pip in your environment

3. Install virtualenv

pip install virtualenv

4. Create a virtual environment

virtualenv <environment-name>

5. Activate the virtual environment

Mac or Linux

source <environment-name>/bin/activate

Windows

<environment-name>\Scripts\activate.bat

6. Install the required packages in the virtual environment

    pip install -r requirements.txt

Testing

It is important that before you do anything, you have the requirements.txt file installed as it is required for the dependencies that are used in this project.

To install all dependencies listed in this file, run the following:

python -m pip install -r requirements.txt

To execute tests, please ensure that you have the pytest module installed. The unittest module is used, however, this is native to Python and does not have to be installed.

To run tests, please ensure that you are in the base directory, where tests and main.py are visible.

To run tests with print output:

pytest -s

To run tests without print output:

pytest

Docker Containerization

We suggest packaging the code in a lightweight Docker container like python-slim and running the code from it. That way, the environment is set and can be run from any environment that supports Docker.

[initd1]

i completely agree, myself being a religious semver person myself. I assume you also mean incrementing patches upon bugfixes? Also I have a question: are any branches to be deleted at any point in time?

Yes. I also mean incrementing patches on Bug fixes as per semver, such as 0.2.1, 0.2.2 etc., however, I would like to be reasonable with the number of version increments, as it can soon cause management overhead (unless some of it can be automated with Github Actions?). My plan is to do a release upon a significant set of changes, or after a particular time frame (such as a sprint of 14 days) or monthly releases. I have a few upcoming features in mind which would warrant incrementing the minor version such as "Alerting via email/webhooks to slack, teams, twitter etc", "accepting subscriptions for HackAlert via different means" etc. Lots of possibilities.

And appreciate the CONTRIBUTION draft. I will incorporate it.

Regarding deleting branches: My plan is to delete branches at least a week after it has been merged, to account for any issues.

[H4ppy-04]

(unless some of it can be automated with Github Actions?).

Funnily enough, i was playing around with a release integration bot called release drafter. It essentially spices up release notes, and is just all around brilliant.