So we want to understand on how we can provide patches/fixes for the same in 2.24 and trunk as well. Do we need to continue development on twoca_sync branch so that you can cherry pick the fixes in 2.24 and merge the same to trunk as well.
We always do new development against trunk (not stable release branches such as 2.24 etc).
If you want to do minor features, minor improvements and bugfixes you can do that directly on trunk. If you want to develop larger new features we appreciate if you do that in a branch and go through the regular review/merge process.
If you need to do bugfixes to what was released in 2.24, you first do the fix in trunk, and then we back-port the fix rev to 2.24 stable.
So we want to understand on how we can provide patches/fixes for the same in 2.24 and trunk as well. Do we need to continue development on twoca_sync branch so that you can cherry pick the fixes in 2.24 and merge the same to trunk as well.
If I understand it correctly, we will continue working on our trunk based branch and provide patches so that you can put them in trunk and also back-port the fix rev to 2.24 stable.
Also we would like to understand the best practice around this. Can we continue using twoca_sync branch (the status of which is ‘merged’) or create a new trunk based branch (the status of which will be ‘development’)
Thanks
Aamer.
···
On Wed, Jul 13, 2016 at 10:21 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Aamer,
thanks for bringing this up.
We always do new development against trunk (not stable release branches such as 2.24 etc).
If you want to do minor features, minor improvements and bugfixes you can do that directly on trunk. If you want to develop larger new features we appreciate if you do that in a branch and go through the regular review/merge process.
If you need to do bugfixes to what was released in 2.24, you first do the fix in trunk, and then we back-port the fix rev to 2.24 stable.
So we want to understand on how we can provide patches/fixes for the same in 2.24 and trunk as well. Do we need to continue development on twoca_sync branch so that you can cherry pick the fixes in 2.24 and merge the same to trunk as well.
What happens when we release a new version of DHIS 2 is that we branch of <2.XX> version (2.24 now latest) and then continue doing development in trunk branch, mainly this means that bugfixes goes into trunk/2,XX and new features into trunk only.
Probably it would be wise to follow this approach for your branch also (twoca_sync-trunk / twoca_sync-2.24) as we do not want to backport big features into 2.24 which can cause issues with a stable branch.
If I understand it correctly, we will continue working on our trunk based branch and provide patches so that you can put them in trunk and also back-port the fix rev to 2.24 stable.
Also we would like to understand the best practice around this. Can we continue using twoca_sync branch (the status of which is ‘merged’) or create a new trunk based branch (the status of which will be ‘development’)
On Wed, Jul 13, 2016 at 10:21 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Aamer,
thanks for bringing this up.
We always do new development against trunk (not stable release branches such as 2.24 etc).
If you want to do minor features, minor improvements and bugfixes you can do that directly on trunk. If you want to develop larger new features we appreciate if you do that in a branch and go through the regular review/merge process.
If you need to do bugfixes to what was released in 2.24, you first do the fix in trunk, and then we back-port the fix rev to 2.24 stable.
So we want to understand on how we can provide patches/fixes for the same in 2.24 and trunk as well. Do we need to continue development on twoca_sync branch so that you can cherry pick the fixes in 2.24 and merge the same to trunk as well.
Once the patches are ready we will provide the details so that you can commit them to the main DHIS 2.24 branch and DHIS trunk as well.
···
On Mon, Jul 25, 2016 at 2:07 PM, Morten Olav Hansen morten@dhis2.org wrote:
Hi Aamer
What happens when we release a new version of DHIS 2 is that we branch of <2.XX> version (2.24 now latest) and then continue doing development in trunk branch, mainly this means that bugfixes goes into trunk/2,XX and new features into trunk only.
Probably it would be wise to follow this approach for your branch also (twoca_sync-trunk / twoca_sync-2.24) as we do not want to backport big features into 2.24 which can cause issues with a stable branch.
If I understand it correctly, we will continue working on our trunk based branch and provide patches so that you can put them in trunk and also back-port the fix rev to 2.24 stable.
Also we would like to understand the best practice around this. Can we continue using twoca_sync branch (the status of which is ‘merged’) or create a new trunk based branch (the status of which will be ‘development’)
Thanks
Aamer.
On Wed, Jul 13, 2016 at 10:21 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Aamer,
thanks for bringing this up.
We always do new development against trunk (not stable release branches such as 2.24 etc).
If you want to do minor features, minor improvements and bugfixes you can do that directly on trunk. If you want to develop larger new features we appreciate if you do that in a branch and go through the regular review/merge process.
If you need to do bugfixes to what was released in 2.24, you first do the fix in trunk, and then we back-port the fix rev to 2.24 stable.
So we want to understand on how we can provide patches/fixes for the same in 2.24 and trunk as well. Do we need to continue development on twoca_sync branch so that you can cherry pick the fixes in 2.24 and merge the same to trunk as well.
Once the patches are ready we will provide the details so that you can commit them to the main DHIS 2.24 branch and DHIS trunk as well.
On Mon, Jul 25, 2016 at 2:07 PM, Morten Olav Hansen morten@dhis2.org wrote:
Hi Aamer
What happens when we release a new version of DHIS 2 is that we branch of <2.XX> version (2.24 now latest) and then continue doing development in trunk branch, mainly this means that bugfixes goes into trunk/2,XX and new features into trunk only.
Probably it would be wise to follow this approach for your branch also (twoca_sync-trunk / twoca_sync-2.24) as we do not want to backport big features into 2.24 which can cause issues with a stable branch.
If I understand it correctly, we will continue working on our trunk based branch and provide patches so that you can put them in trunk and also back-port the fix rev to 2.24 stable.
Also we would like to understand the best practice around this. Can we continue using twoca_sync branch (the status of which is ‘merged’) or create a new trunk based branch (the status of which will be ‘development’)
Thanks
Aamer.
On Wed, Jul 13, 2016 at 10:21 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Aamer,
thanks for bringing this up.
We always do new development against trunk (not stable release branches such as 2.24 etc).
If you want to do minor features, minor improvements and bugfixes you can do that directly on trunk. If you want to develop larger new features we appreciate if you do that in a branch and go through the regular review/merge process.
If you need to do bugfixes to what was released in 2.24, you first do the fix in trunk, and then we back-port the fix rev to 2.24 stable.
So we want to understand on how we can provide patches/fixes for the same in 2.24 and trunk as well. Do we need to continue development on twoca_sync branch so that you can cherry pick the fixes in 2.24 and merge the same to trunk as well.