Changing pharo default branch to development
As we discussed in ESUG, and since this is a cheap change to do in the airport, we are making the development branch in pharo the default branch. This will help avoiding accidental pull requests targeting master instead of development. For those who may ask, we will not remove the master branch yet. This is because we are in the airport doing this and we would like to give it a better thought :). Guille, Esteban and Pablo -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
Thanks you guys! I will remove a lot of mistakes :) I think that when we can simplify without losing anything, it is a clear sign that we should do it. Stef On Sat, Sep 9, 2017 at 10:53 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
As we discussed in ESUG, and since this is a cheap change to do in the airport, we are making the development branch in pharo the default branch.
This will help avoiding accidental pull requests targeting master instead of development.
For those who may ask, we will not remove the master branch yet. This is because we are in the airport doing this and we would like to give it a better thought :).
Guille, Esteban and Pablo
--
Guille Polito
Research Engineer
French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr>
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
On 09-09-17 10:53, Guillermo Polito wrote:
For those who may ask, we will not remove the master branch yet. This is because we are in the airport doing this and we would like to give it a better thought .
Let me share my thoughts, please tell me which ones need improvement: 1 Each branch creates overhead, just by existing: it means having to choose where to commit, and the opportunity to make mistakes. Therefore: only add branches that provide value, and remove ones that no longer do. 2 If a branch exists for a long time, it will diverge from trunk because trunk changes. The longer it exists the more difficult it becomes to understand the differences between branches. With git we can decrease the gap by using rebase. Therefore: keep the lifetime of branches small and do issue fixes as close as possible to trunk, using rebase where possible. 3 We want to regularly provide releases to provide people building on top of them feature and api stability. Therefore, each release becomes a branch. 4 We want to do issue fixes to trunk and supported releases. A separate branch for the issue fix makes it easier to back port issues. 5 To ensure the quality of changes, we use a separate repository instead of an extra branch. The separation of master and development branches does not add value, so should be removed. Looking forward to your thoughts, Stephan
participants (3)
-
Guillermo Polito -
stephan -
Stephane Ducasse