-
Notifications
You must be signed in to change notification settings - Fork 227
Vienna Development Cycle
This is inspired mainly by Firefox and Mira processes, but it has been simplified to fit the size of the ViennaRSS team.
Classification of issues :
- level 0 : critical-bug
- level 1 : bug
- level 2 : improvement / feature request / development feature
Classification criteria :
- bug : must be reproductible. A clear description has been provided and a developer has confirmed he is able to reproduce the bug at will and can help in debugging it.
- critical-bug : a bug that is present in current release version (
stablebranch), needs to be fixed as soon as possible, and can't wait the end of the current development cycle.
Any admin has a veto right regarding the labelling of an issue as a bug (rather than an improvement) or a critical-bug (rather than an "ordinary" bug). This is done because these specific statuses allow expedited processes which may complicate subsequent merges.
-
dev-dddd (the dddd number refers to the issue describing the goal of the development) -
master(betas) (will mature to become the next X.X.0 release) -
stable(releases) (current X.X.X release) -
oldstable(releases compatible with version(s) of macOS older than the current minimum requirement)
Merges into master, stable or oldstable MUST be done through a Pull Request and MUST be reviewed.
As a general rule, merges into stable should be done from master.
master ⇢ stable
Changes to solve anything else than bugs are NEVER directly added to stable.
There is also a localizations branch where Crowdin updates are pushed. The role of this branch can be seen in Updating localizations.
The development cycle is two months, the first month being focused on modernization work or addition of features and the second month being focused on stabilization.
The end of the development cycle and the release of a new X.X.0 version should occur on last Sundays of January, March, May, July, September and November.
Betas of the future X.X.0 version should be build after significant evolutions of master; they are to be expected at least on last Sundays of February, April, June, August, October and December (unless nothing new has occurred in between…).
Solutions for critical bugs are pulled directly into stable. Whenever multiple solutions are proposed, the solution having the least impact on existing stable code will be privileged and it will be applied as soon as possible.
Longer term solutions can still be proposed, but they will have to go through the master stage.
The logic behind this is that once the bug in itself is closed, anything else — even if it is related to the bug — should be considered as an improvement request.
The hotfix is applied to stable and master.
stable is tested then tagged with a new version number.
In cases where there is enough demand and it does not require too much work, some changes to solve critical bugs MAY be cherry-picked from stable to be pulled into oldstable.
oldstable is therefore tested then tagged with a new version number.
Solutions for bugs MAY be pulled directly into stable, but are more frequently presented to master. During the second part of the development cycle, whenever multiple solutions are proposed, the solution having the least impact on existing master code should be privileged.
It remains possible to add better "long term" solutions, but they will have to wait the start of the next development cycle to be merged.
It is recommended that extensive changes are presented at an early stage of the two months development cycle.
This is especially true for architectural changes or technical modernizations which can considerably affect Vienna.xcodeproj/project.pbxproj and might cause difficulties on future merges.
It is developer's choice to either submit a pull request into master or request the creation of a specific dev-dddd branch. In general, features that may take a long time to develop and stabilize should be started on a dev-dddd branch. Smaller size changes can be presented directly to be merged into master, but developers should not expect that big pull requests presented near the end of the development cycle will be quickly reviewed and accepted.
Considering two months represent 7 to 8 weeks, here could be the typical story of a release :
Focus is on development of new features on master and dev-dddd branches.
Open discussion.
The release administration group makes go/no go decisions on dev-dddd branches which can be considered stable enough to make it into master.
Issues milestones and roadmap documents are updated accordingly.
Reorganization and squash of the commits in dev-dddd branches can be done to hide the sausage making process. Once approved, dev-dddd branches should be rebased before being merged into master.
Base localization is frozen.
Base localization files are updated into Crowdin.
CHANGES and notes.html files are updated.
A new beta of the future X.X.0 version is build and uploaded.
Work can continue in dev-dddd branches but priority should be given to stabilization of master regarding issues that might arise as new features and pieces of code are exposed to the wider beta audience.
Localization teams perform their work on the product in Crowdin. Localized strings are weekly reimported from Crowdin.
Betas should be frequently build and uploaded.
The release administration group make a review of master. The removal of a feature from master should remain exceptional (last minute efforts to fix or work around residual bugs will generally be preferred), but it cannot be completely excluded (if this might arise, the cancellation would be done by an additional pull request into master).
Final localized strings are reimported from Crowdin.
CHANGES and notes.html files are updated, then master is merged into stable (any conflict should be solved by preserving changes made in master: combinations of git merge -s recursive -X theirs --squash -e [<tree-ish>] and git checkout --theirs [<tree-ish>] [<paths>...] with stable being the current branch might be handy).
The new version number X.X.0 is tagged and uploaded.
It is advised that maintainers of dev-dddd branches rebase them regularly on current master.
dev-dddd branches stalled for 4 months or more will be deleted from the ViennaRSS/vienna-rss repository without prior warning.