-
Notifications
You must be signed in to change notification settings - Fork 17
flow and versioning changes
This issue is divided in 2 different changes propose. But it's important to notice that both together should bring more value to the table.
- A complete long-term change history of every file: This means every change made by many individuals over the years. Changes include the creation and deletion of files as well as edits to their contents. Different VCS tools differ on how well they handle renaming and moving of files. This history should also include the author, date and written notes on the purpose of each change. Having the complete history enables going back to previous versions to help in root cause analysis for bugs and it is crucial when needing to fix problems in older versions of software. If the software is being actively worked on, almost everything can be considered an "older version" of the software.
- Branching and merging: Having team members work concurrently is a no-brainer, but even individuals working on their own can benefit from the ability to work on independent streams of changes. Creating a "branch" in VCS tools keeps multiple streams of work independent from each other while also providing the facility to merge that work back together, enabling developers to verify that the changes on each branch do not conflict. Many software teams adopt a practice of branching for each feature or perhaps branching for each release, or both. There are many different workflows that teams can choose from when they decide how to make use of branching and merging facilities in VCS.
- Traceability: Being able to trace each change made to the software and connect it to project management and bug tracking software such as Jira, and being able to annotate each change with a message describing the purpose and intent of the change can help not only with root cause analysis and other forensics. Having the annotated history of the code at your fingertips when you are reading the code, trying to understand what it is doing and why it is so designed can enable developers to make correct and harmonious changes that are in accord with the intended long-term design of the system. This can be especially important for working effectively with legacy code and is crucial in enabling developers to estimate future work with any accuracy.
Actually passport versioning has been (strangely) linked to Gluu Server version. By the versioning bennefits perspective, there is almost NO bennefit at all to passport, given that passport semantic versioning, changelogs, etc is None.
To maintain release changelog without a own independent versionig brings unecessary complexity.
Being passport a Gluu Server module, it should have it's own version control, with descriptive commits, active changelog, coding convention, and versioning.
Following SemVer:
Version X.Y.Z
X = breaking change
Y = new feature
Z = fixes / patches
Given we have the branches:
-
master: master is ready to deploy and run jenkins jobs -
develop: is the staging branch, all features / bugfixes are merged here. When merging / raising PR, gitflow actions job will run tests (unit, functional...), coverage, linting (for code convention and coding errors) and do other jobs needed to ensure minimum quality.
After the PR is merged in develop and passed on github actions checks, they are merged to master with version as a tag, and release changelogs are updated.