Changes between Version 6 and Version 7 of TracDev/DevelopmentWorkflow
- Timestamp:
- Jul 27, 2015, 9:29:23 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/DevelopmentWorkflow
v6 v7 1 1 = Development Workflow for Trac 2 2 3 We don't have very formal rules, so consider the following as a summary of our current practices. 4 5 == Objective 6 7 The public branches listed in TracDownload#LatestDevelopmentSourceCode should remain bug free and always usable from an end-user perspective, as we support installing directly from the branches. 3 The public branches listed in TracDownload#LatestDevelopmentSourceCode should remain bug free and always usable from an end-user perspective, as we support installing directly from the branches. To achieve this, we follow the practices listed below. 8 4 9 5 == Initial code review 10 6 11 Except for trivial fixes, it's usually a good idea to start with a patch or an experimental branch, in orderto provide some visibility of the changes to the other contributors.7 Except for trivial fixes, it's usually a good idea to start with a patch or an experimental branch, to provide some visibility of the changes to the other contributors. 12 8 13 Thepatch is always attached to a ticket. If there is no ticket, then create one and attach the patch to it.9 A patch is always attached to a ticket. If there is no ticket, then create one and attach the patch to it. 14 10 15 When it appears thatthere are many iterations or spin-off changes needed, it's a good idea to start a branch, either in the svn [source:sandbox] for those who have the commit permission or inside an external DVCS repository, by forking our Mercurial or Git mirrors (see TracRepositories).11 When there are many iterations or spin-off changes needed, it's a good idea to start a branch, either in the svn [source:sandbox] for those who have the commit permission or inside an external DVCS repository, by forking our Mercurial or Git mirrors (see TracRepositories). 16 12 17 13 == Integration in release branches 18 14 19 We commit bug fixes first on one of the stable branches, eg [source:branches/0.12-stable], then merge the fix to lat ter branches using svn's mergeinfo support.15 We commit bug fixes first on one of the stable branches, eg [source:branches/0.12-stable], then merge the fix to later branches using svn's mergeinfo support. 20 16 21 17 Merging in this direction (//porting// or //forward porting//) makes it quite easy to merge all pending changes from one stable branch to the next, eg [source:branches/0.12-stable 0.12-stable] to [source:branches/1.0-stable 1.0-stable], then to [source:trunk]. This workflow is much simpler than the opposite one, //back porting//, which involves cherry-picking or careful "blocking" of changes which shouldn't be merged back. The SCM tools have generally better support for merging in this forward direction, even Subversion since v1.5. … … 23 19 Here's a walk through example. We start by hacking on [source:branches/0.12-stable 0.12-stable]: 24 20 {{{#!sh 25 0.12-stable$ ed trac/attachment.py # or your other favorite editor ;-)21 0.12-stable$ ed trac/attachment.py # or your other favorite editor 26 22 0.12-stable$ make test 27 23 ... … … 56 52 - Use newer APIs and conventions, eg the DatabaseApi#Trac0.13API; see the ApiChanges subpage for the corresponding target branch. 57 53 58 '''Note''': onecan always review what are the pending changes in Trac by looking at the `svn:mergeinfo` property which shows the '''eligible''' set of changesets, when viewing the target branch in the TracBrowser, eg [source:trunk].54 '''Note''': you can always review what are the pending changes in Trac by looking at the `svn:mergeinfo` property which shows the '''eligible''' set of changesets, when viewing the target branch in the TracBrowser, eg [source:trunk].