# Testing knowledge about the new KERI Suite Git Workflow

## Branching, Tagging, and Releasing Strategy Update Proposal Exam

## Instructions:
- For each question, select the correct answer by clicking the checkbox.
- After each question, there will be an explanation of the correct answer and why the other options are less suitable.

---

### 1. What was the primary motivation behind proposing a new branching strategy for KERIpy?
- [ ] A. To introduce GitFlow to new developers
- [ ] B. To address issues arising from rapid development and external dependencies
- [ ] C. To reduce the frequency of software releases
- [ ] D. To shift towards a closed source project model

**Correct Answer:** B. To address issues arising from rapid development and external dependencies.

**Explanation:** The motivation for the new strategy is due to the unwieldy nature of the current process, which is causing more work than necessary and has led to a lost feature. This problem stems from handling rapid development and external dependencies ineffectively.

---

### 2. What does the current GitFlow strategy in KERIpy primarily rely on?
- [ ] A. A single long-living branch
- [ ] B. Multiple feature branches without a main branch
- [ ] C. Two long-living branches: main and development
- [ ] D. Ad-hoc creation of branches as needed

**Correct Answer:** C. Two long-living branches: main and development.

**Explanation:** The GitFlow workflow currently utilized relies on two long-living branches, which are the main and development branches, for managing features and releases.

---

### 3. What challenge has the GitFlow strategy introduced for KERIpy?
- [ ] A. Simplification of the development process
- [ ] B. Increased collaboration among developers
- [ ] C. Difficulty in resolving merge conflicts between branches
- [ ] D. Decreased software release time

**Correct Answer:** C. Difficulty in resolving merge conflicts between branches.

**Explanation:** The challenge with GitFlow is the difficulty in resolving merge conflicts due to divergent code changes in both the development and main branches, especially when new releases are being prepared.

---

### 4. How does the proposed Feature Based Workflow differ from the current GitFlow approach in terms of branching?
- [ ] A. It introduces more long-living branches for better organization
- [ ] B. It eliminates the development branch, leaving only one long-living branch
- [ ] C. It requires feature branches to be created off the development branch instead of the main branch
- [ ] D. It mandates that all development be done directly on the main branch without feature branches

**Correct Answer:** B. It eliminates the development branch, leaving only one long-living branch.

**Explanation:** The proposed Feature Based Workflow simplifies the process by removing the development branch, meaning all feature work will branch off from and merge back into the main branch.

---

### 5. What is a key requirement for the code on the main branch in the proposed Feature Based Workflow?
- [ ] A. The code must be in a beta state
- [ ] B. The code must be "production ready"
- [ ] C. The code can be in a development state
- [ ] D. The code should not be tested

**Correct Answer:** B. The code must be "production ready".

**Explanation:** A crucial difference in the proposed workflow is that the code on the main branch must always be production ready, unlike the current model where the main branch is synonymous with the current release.

---

### 6. Which of the following is true about creating a new feature in the proposed Feature Based Workflow?
- [ ] A. Developers must create features directly on the main branch
- [ ] B. Developers create a new branch from main for their new feature
- [ ] C. Features are developed on a separate long-living feature branch
- [ ] D. All development happens on the development branch before merging into main

**Correct Answer:** B. Developers create a new branch from main for their new feature.

**Explanation:** In the proposed workflow, developers will pull the latest main branch, create a new branch from main for their new feature, and eventually merge back into main, ensuring the main branch remains production ready.

---

### 7. What is the first step in creating a new release in the proposed New Release Workflow?
- [ ] A. Immediately create a new tag for the release
- [ ] B. Pull the latest main branch and ensure all tests pass
- [ ] C. Update the version information in all files
- [ ] D. Push the new branch to upstream

**Correct Answer:** B. Pull the latest main branch and ensure all tests pass.

**Explanation:** The first step in creating a new release involves pulling the latest version of the main branch and ensuring that all tests and scripts pass, confirming the code's readiness for release.

---

### 8. In the proposed patch workflow, what is the initial step for creating a new patch version?
- [ ] A. Directly update the version information in setup.py
- [ ] B. Checkout the relevant unbounded term branch for the version needing a patch
- [ ] C. Push the new patch directly to the main branch
- [ ] D. Create a new feature branch for the patch

**Correct Answer:** B. Checkout the relevant unbounded term branch for the version needing a patch.

**Explanation:** For patching a specific version, developers are required to checkout the corresponding unbounded term branch designated for patch releases (e.g., r2.3.x for version 2.3.0 patches), ensuring organized management of patches.

---

### 9. What problem does the proposed new strategy aim to solve regarding patching old versions?
- [ ] A. Increasing the speed of new feature development
- [ ] B. Facilitating the removal of the main branch
- [ ] C. Providing a structured method for patching old versions
- [ ] D. Eliminating the need for semantic versioning

**Correct Answer:** C. Providing a structured method for patching old versions.

**Explanation:** The new strategy addresses how to effectively create patches for older versions when the main branch has progressed, suggesting the creation of long-living branches from tags of older versions for this purpose.

---

### 10. Which workflow model does the proposed strategy intend to replace GitFlow with?
- [ ] A. Centralized Workflow
- [ ] B. Feature Branch Workflow
- [ ] C. Forking Workflow
- [ ] D. Feature Based Workflow

**Correct Answer:** D. Feature Based Workflow.

**Explanation:** The proposal suggests transitioning to a Feature Based Workflow from GitFlow, emphasizing a simplified structure with a single long-living branch and feature branches merging back into this main branch.

---

### 11. What is the suggested method for dealing with features intended for future releases in the proposed workflow?
- [ ] A. Merge them into a separate staging branch
- [ ] B. Keep them on individual developer forks until release
- [ ] C. Merge them directly into the main branch as they are developed
- [ ] D. Store them in a dedicated feature storage repository

**Correct Answer:** C. Merge them directly into the main branch as they are developed.

**Explanation:** The proposed workflow suggests that all feature work, intended for the next release or otherwise, be merged into the main branch once ready, ensuring it remains production-ready at all times.

---

### 12. In the context of the proposed changes, what is the significance of a branch being "production ready"?
- [ ] A. It is ready to be discarded
- [ ] B. It is in a stable state and can be released at any time
- [ ] C. It needs further testing before merging
- [ ] D. It is only for internal use and not for public release

**Correct Answer:** B. It is in a stable state and can be released at any time.

**Explanation:** The term "production ready" implies that the code in the main branch is always in a state that could be released to users, marking a key requirement for the main branch in the proposed workflow.

---

### 13. What does the establishment of long-living branches for each release that requires future patches imply about the proposed workflow's approach to version control?
- [ ] A. A preference for a monolithic approach to development
- [ ] B. An emphasis on flexibility and responsiveness to issues in released versions
- [ ] C. A shift away from traditional semantic versioning practices
- [ ] D. A consolidation of development efforts into a single, linear history

**Correct Answer:** B. An emphasis on flexibility and responsiveness to issues in released versions.

**Explanation:** By creating dedicated branches for managing patches of released versions, the proposed workflow highlights a tailored approach to maintaining the integrity and security of software across multiple versions.

---

### 14. How might the proposed workflow facilitate or hinder the practice of cherry-picking commits between branches?
- [ ] A. Facilitate, by reducing the branch complexity and making it easier to identify relevant commits
- [ ] B. Hinder, by increasing the frequency of conflicts due to the convergence of development in the main branch
- [ ] C. Facilitate, by automatically syncing changes across all relevant branches
- [ ] D. Hinder, by eliminating the development branch, thus removing the typical source branch for cherry-picking

**Correct Answer:** A. Facilitate, by reducing the branch complexity and making it easier to identify relevant commits.

**Explanation:** With a simpler branch structure and clear delineation of feature and patch branches, identifying and cherry-picking commits becomes more straightforward, enhancing the efficiency of incorporating specific changes across different versions.

---

### 15. Reflecting on the proposed changes, what is a critical consideration for the maintainers in ensuring the success of the Feature Based Workflow?
- [ ] A. Determining the optimal number of feature branches to maintain concurrently
- [ ] B. Establishing strict guidelines and automation for testing and merging to maintain the production-ready status of the main branch
- [ ] C. Deciding on a fixed schedule for creating and merging feature branches
- [ ] D. Coordinating the removal of old branches to prevent clutter in the repository

**Correct Answer:** B. Establishing strict guidelines and automation for testing and merging to maintain the production-ready status of the main branch.

**Explanation:** The success of the workflow heavily relies on rigorous testing, review, and automation practices to ensure that all changes merged into the main branch uphold the production-ready quality standard.

---

### 16. What major change does the new strategy propose regarding the handling of patches for previous versions?
- [ ] A. Ignoring patches for older versions to focus on future development
- [ ] B. Creating a dedicated patch team to handle all old versions
- [ ] C. Establishing long-living branches for each release that might need future patches
- [ ] D. Automatically merging patches into all versions simultaneously

**Correct Answer:** C. Establishing long-living branches for each release that might need future patches.

**Explanation:** To manage patches for older versions more effectively, the proposal suggests creating long-living branches from the tags of those versions, providing a clear pathway for applying and managing patches.

---

### 17. In the proposed workflow, what action is recommended immediately after a new release tag is pushed?
- [ ] A. Delete the main branch
- [ ] B. Publish new release artifacts like PyPi packages and Docker images
- [ ] C. Start working on the next major version
- [ ] D. Freeze all development for a review period

**Correct Answer:** B. Publish new release artifacts like PyPi packages and Docker images.

**Explanation:** Following the creation and pushing of a new release tag, the immediate next steps involve publishing the corresponding release artifacts, such as PyPi packages and Docker images, to make the release available to users.

---

### 18. Which of the following best describes the advantage of transitioning to a Feature Based Workflow from GitFlow in the context of patch management?
- [ ] A. It simplifies the creation of new features by removing the need for branches.
- [ ] B. It enhances the visibility of feature development by requiring multiple development branches.
- [ ] C. It allows for direct patch application to the production-ready main branch, bypassing the development branch.
- [ ] D. It streamlines patch application by allowing developers to determine patch applicability at the time of creation.

**Correct Answer:** D. It streamlines patch application by allowing developers to determine patch applicability at the time of creation.

**Explanation:** The proposed workflow offers a more flexible approach to patch management, allowing developers to directly decide where else a patch should be applied, thus streamlining the process.

---

### 19. In the context of the proposed Feature Based Workflow, what is the implied benefit of having the main branch always in a "production-ready" state?
- [ ] A. It negates the need for a separate testing or staging environment.
- [ ] B. It facilitates continuous integration/continuous deployment (CI/CD) practices by ensuring that any version of the main can be deployed.
- [ ] C. It simplifies branch management by reducing the number of branches.
- [ ] D. It eliminates the need for version tagging and release branches.

**Correct Answer:** B. It facilitates continuous integration/continuous deployment (CI/CD) practices by ensuring that any version of the main can be deployed.

**Explanation:** Keeping the main branch in a production-ready state aligns with CI/CD methodologies, where the latest stable version of the software can be deployed at any time, enhancing the efficiency of the development process.

---

### 20. Considering the proposed switch to a Feature Based Workflow, what challenge might arise from merging feature branches directly into main?
- [ ] A. Increased risk of introducing unstable code into the production environment
- [ ] B. Difficulty in tracking which features belong to which release
- [ ] C. Reduced complexity in managing branches and merges
- [ ] D. Enhanced ease in reverting features if they do not meet quality standards

**Correct Answer:** B. Difficulty in tracking which features belong to which release.

**Explanation:** While merging features directly into the main branch simplifies the branch structure, it could complicate understanding which features are included in each release without meticulous tagging and documentation.

---

### 21. How does the proposed new release workflow handle the creation of branches for future patches?
- [ ] A. By creating a new branch for each patch ahead of time
- [ ] B. By waiting until a patch is needed before creating a branch
- [ ] C. By establishing unbounded term branches named with an 'r', the version numbers, and an 'x'
- [ ] D. By automating branch creation through a CI/CD pipeline based on the number of commits

**Correct Answer:** C. By establishing unbounded term branches named with an 'r', the version numbers, and an 'x'.

**Explanation:** This method for naming branches intended for future patches provides a systematic approach to manage and locate patches for specific release versions, facilitating organization and access.

---

### 22. What is a potential downside to eliminating the development branch in favor of a single, production-ready main branch?
- [ ] A. Decreased clarity in the distinction between development and production-ready code
- [ ] B. Increased difficulty in managing hotfixes due to the lack of a dedicated branch
- [ ] C. The necessity for more rigorous testing and review processes before merging features
- [ ] D. A reduction in the number of branches makes it easier to manage project workflows

**Correct Answer:** C. The necessity for more rigorous testing and review processes before merging features.

**Explanation:** With all development occurring directly on the main branch, there's a heightened need for strict quality control measures to ensure that new commits do not destabilize the production-ready state of the branch.

---

### 23. In the proposed Feature Based Workflow, how is the process of tagging a new release described?
- [ ] A. As an automatic step triggered by merging a feature branch into main
- [ ] B. As a manual process that occurs after updating version information and ensuring all tests pass
- [ ] C. As a periodic activity decided by the core maintainers irrespective of the state of main
- [ ] D. As an unnecessary step, given the continuous deployment nature of the workflow

**Correct Answer:** B. As a manual process that occurs after updating version information and ensuring all tests pass.

**Explanation:** The detailed steps for tagging a new release emphasize the importance of manual oversight in version management, ensuring that releases are deliberate and tested.

---

### 24. What does the establishment of long-living branches for each release that requires future patches imply about the proposed workflow's approach to version control?
- [ ] A. A preference for a monolithic approach to development
- [ ] B. An emphasis on flexibility and responsiveness to issues in released versions
- [ ] C. A shift away from traditional semantic versioning practices
- [ ] D. A consolidation of development efforts into a single, linear history

**Correct Answer:** B. An emphasis on flexibility and responsiveness to issues in released versions.

**Explanation:** By creating dedicated branches for managing patches of released versions, the proposed workflow highlights a tailored approach to maintaining the integrity and security of software across multiple versions.

---

### 25. How might the proposed workflow facilitate or hinder the practice of cherry-picking commits between branches?
- [ ] A. Facilitate, by reducing the branch complexity and making it easier to identify relevant commits
- [ ] B. Hinder, by increasing the frequency of conflicts due to the convergence of development in the main branch
- [ ] C. Facilitate, by automatically syncing changes across all relevant branches
- [ ] D. Hinder, by eliminating the development branch, thus removing the typical source branch for
cherry-picking

**Correct Answer:** A. Facilitate, by reducing the branch complexity and making it easier to identify relevant commits.

**Explanation:** With a simpler branch structure and clear delineation of feature and patch branches, identifying and cherry-picking commits becomes more straightforward, enhancing the efficiency of incorporating specific changes across different versions.

---

### 26. Reflecting on the proposed changes, what is a critical consideration for the maintainers in ensuring the success of the Feature Based Workflow?
- [ ] A. Determining the optimal number of feature branches to maintain concurrently
- [ ] B. Establishing strict guidelines and automation for testing and merging to maintain the production-ready status of the main branch
- [ ] C. Deciding on a fixed schedule for creating and merging feature branches
- [ ] D. Coordinating the removal of old branches to prevent clutter in the repository

**Correct Answer:** B. Establishing strict guidelines and automation for testing and merging to maintain the production-ready status of the main branch.

**Explanation:** The success of the workflow heavily relies on rigorous testing, review, and automation practices to ensure that all changes merged into the main branch uphold the production-ready quality standard.

---

### 27. What problem does the proposed new strategy aim to solve regarding patching old versions?
- [ ] A. Increasing the speed of new feature development
- [ ] B. Facilitating the removal of the main branch
- [ ] C. Providing a structured method for patching old versions
- [ ] D. Eliminating the need for semantic versioning

**Correct Answer:** C. Providing a structured method for patching old versions.

**Explanation:** The new strategy addresses how to effectively create patches for older versions when the main branch has progressed, suggesting the creation of long-living branches from tags of older versions for this purpose.

---

### 28. Which of the following is true about creating a new feature in the proposed Feature Based Workflow?
- [ ] A. Developers must create features directly on the main branch
- [ ] B. Developers create a new branch from main for their new feature
- [ ] C. Features are developed on a separate long-living feature branch
- [ ] D. All development happens on the development branch before merging into main

**Correct Answer:** B. Developers create a new branch from main for their new feature.

**Explanation:** In the proposed workflow, developers will pull the latest main branch, create a new branch from main for their new feature, and eventually merge back into main, ensuring the main branch remains production ready.

---

### 29. What is a key requirement for the code on the main branch in the proposed Feature Based Workflow?
- [ ] A. The code must be in a beta state
- [ ] B. The code must be "production ready"
- [ ] C. The code can be in a development state
- [ ] D. The code should not be tested

**Correct Answer:** B. The code must be "production ready".

**Explanation:** A crucial difference in the proposed workflow is that the code on the main branch must always be production ready, unlike the current model where the main branch is synonymous with the current release.

---

### 30. What challenge has the GitFlow strategy introduced for KERIpy?
- [ ] A. Simplification of the development process
- [ ] B. Increased collaboration among developers
- [ ] C. Difficulty in resolving merge conflicts between branches
- [ ] D. Decreased software release time

**Correct Answer:** C. Difficulty in resolving merge conflicts between branches.

**Explanation:** The challenge with GitFlow is the difficulty in resolving merge conflicts due to divergent code changes in both the development and main branches, especially when new releases are being prepared.