Changes between Version 2 and Version 3 of TracDev/DevelopmentWorkflow

Timestamp:

May 14, 2011, 4:40:45 PM (13 years ago)

Author:

Christian Boos

Comment:

document possible adaptations needed when merging

TracDev/DevelopmentWorkflow

@@ -13 +13 @@
 
 The patch is generally attached to a ticket.
-When there are many iterations or spin-off changes, it's generally 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).
+When it appears that 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).
 
 
@@ -20 +20 @@
 The general idea is that we commit bug fixes first on one of the stable branch (e.g. [source:branches/0.12-stable]), then merge the fix to latter branches using svn's mergeinfo support.
 
-Merging in this direction (//porting// or //forward porting//) makes it quite easy to merge all pending changes from one stable branch to the next, e.g. [source:branches/0.12-stable 0.12-stable] to [source:branches/0.13-stable 0.13-stable] (when we'll have it), 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 direction, even Subversion since version 1.5 ;-)
+Merging in this direction (//porting// or //forward porting//) makes it quite easy to merge all pending changes from one stable branch to the next, e.g. [source:branches/0.12-stable 0.12-stable] to [source:branches/0.13-stable 0.13-stable] (when we'll have it), 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 version 1.5 ;-)
 
 Here's a walk through example. We start by hacking on 
@@ -42 +42 @@
 trunk$ svn ci -m "0.13dev: Merged from 0.12-stable."
 }}}
+Among the possible porting related fixes that should be done when porting:
+ - use Python idioms adapted to the minimal version on the branch (e.g. for 0.12 the baseline is Python 2.4, for trunk it's 2.5; this means that among other things we can use `with ...` as appropriate)
+ - use newer APIs and conventions (e.g. the DatabaseApi#Trac0.13API); see the ApiChanges subpage for the corresponding target branch
+
 
 Note: one 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 (e.g. [source:trunk])