[VOTE] Branching policy for 1.0
Hi, Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them: Option 1 (current policy): ==================== * Work on trunk till we cut the RC. At that point in time create a branch Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch) Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue). Option 2: ======== * Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1. Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on. Please cast your votes. I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com
+1 for option 2 On 1/25/07, Vincent Massol <[email protected]> wrote:
Hi,
Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them:
Option 1 (current policy): ====================
* Work on trunk till we cut the RC. At that point in time create a branch
Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch)
Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue).
Option 2: ========
* Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1.
Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues
Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on.
Please cast your votes.
I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline.
Thanks -Vincent
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
-- You receive this message as a subscriber of the [email protected] list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
+1 for the second option On 1/25/07, Vincent Massol <[email protected]> wrote:
Hi,
Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them:
Option 1 (current policy): ====================
* Work on trunk till we cut the RC. At that point in time create a branch
Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch)
Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue).
Option 2: ========
* Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1.
Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues
Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on.
Please cast your votes.
I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline.
Thanks -Vincent
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Hi Vincent ! I'm +1 for the second option Best regards ! - Phung Nam. On 1/25/07, Vincent Massol <[email protected]> wrote:
Hi,
Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them:
Option 1 (current policy): ====================
* Work on trunk till we cut the RC. At that point in time create a branch
Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch)
Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue).
Option 2: ========
* Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1.
Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues
Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on.
Please cast your votes.
I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline.
Thanks -Vincent
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
-- You receive this message as a subscriber of the [email protected] list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
+1 In this scenario we would put Curriki at least on the 1.0 branch. I was even thinking creating a Curriki branch. We want a high level of stability on what we get from XWiki in the Curriki project. This scenario requires a lot of discipline to not forget to merge 1.0 code into the trunk or vice-versa. Could we get from those who know best some efficient ways to merge code from the branch to the trunk and vice-versa. Everytime I do some merges I'm not sure about what I'm doing. Ludovic Vincent Massol a écrit :
Hi,
Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them:
Option 1 (current policy): ====================
* Work on trunk till we cut the RC. At that point in time create a branch
Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch)
Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue).
Option 2: ========
* Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1.
Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues
Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on.
Please cast your votes.
I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline.
Thanks -Vincent
___________________________________________________________________________Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
+1 for the second option. 2007/1/26, Ludovic Dubost <[email protected]>:
Could we get from those who know best some efficient ways to merge code from the branch to the trunk and vice-versa. Everytime I do some merges I'm not sure about what I'm doing.
+1 Merges are always painful for me :) JV.
On 1/26/07, Jean-Vincent Drean <[email protected]> wrote:
+1 for the second option.
2007/1/26, Ludovic Dubost <[email protected]>:
Could we get from those who know best some efficient ways to merge code from the branch to the trunk and vice-versa. Everytime I do some merges I'm not sure about what I'm doing.
+1
Merges are always painful for me :)
Merges are always painful for everyone. This is why I'm always advocating not doing them... (which is what I do on all my projects - Here we are currently not good enough in term of automated tests and quality in general to do this). Here's how to do it with the svn command line client: svn merge --revision 2021:2028 svn+ssh://[email protected]/svnroot/xwiki/xwiki/trunk XWIKI_1_0 Note: This will merge revisions 2022 to 2028 included. You must always specify a revision *before* the one you wish to merge This command was applied in trunk. If you wish to merge from 1.0 to trunk the go in 1.0 and merge to trunk. If you're using a different svn client then it all depends on your client... Hope it helps, -Vincent
Result: 7 +1 - Sergiu - Marta - Sebastien - Nam - Ludovic - Jean-Vincent This vote is passed and I'll create the 1.0 branch tomorrow. Make sure you all: - switch to the 1.0 branch for 1.0 development - use the trunk for 1.1 development - Merge *immediately* on the trunk when you make a change on the 1.0 branch Thanks -Vincent On Jan 25, 2007, at 10:15 AM, Vincent Massol wrote:
Hi,
Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them:
Option 1 (current policy): ====================
* Work on trunk till we cut the RC. At that point in time create a branch
Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch)
Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue).
Option 2: ========
* Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1.
Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues
Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on.
Please cast your votes.
I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline.
Thanks -Vincent
______________________________________________________________________ _____Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
-- You receive this message as a subscriber of the xwiki- [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
On Jan 31, 2007, at 8:46 PM, Vincent Massol wrote:
Result: 7 +1
- Sergiu - Marta - Sebastien - Nam - Ludovic - Jean-Vincent
This vote is passed and I'll create the 1.0 branch tomorrow.
Done. -Vincent
Make sure you all: - switch to the 1.0 branch for 1.0 development - use the trunk for 1.1 development - Merge *immediately* on the trunk when you make a change on the 1.0 branch
Thanks -Vincent
On Jan 25, 2007, at 10:15 AM, Vincent Massol wrote:
Hi,
Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them:
Option 1 (current policy): ====================
* Work on trunk till we cut the RC. At that point in time create a branch
Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch)
Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue).
Option 2: ========
* Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1.
Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues
Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on.
Please cast your votes.
I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline.
Thanks -Vincent
_____________________________________________________________________ ______Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
-- You receive this message as a subscriber of the xwiki- [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http:// www.objectweb.org/wws
______________________________________________________________________ _____ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
-- You receive this message as a subscriber of the xwiki- [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
participants (7)
-
Jean-Vincent Drean -
Ludovic Dubost -
Marta Girdea -
Phung Nam -
Sergiu Dumitriu -
Sébastien Gaïde -
Vincent Massol