On 2013-02-28 00:39, Stefano Lattarini wrote:
On 02/28/2013 12:00 AM, Peter Rosin wrote:
[SNIP]
What I meant was that you can use (some of) my above proposed merges
to go forward with the new role for master instead of requiring help
from Savannah to allow rewriting master.
So... now are
Stefano Lattarini stefano.lattar...@gmail.com writes:
So we should maybe go (after the next major release) with this naming
scheme for the branches?
* maint - for next micro version
* stable - for next minor version
* master - for next major version
That seems to match common
Stefano Lattarini stefano.lattar...@gmail.com writes:
And while you *might* have changed my mind before (because you have
valid points, and maybe it would have better to err on the side of
safety), I have now already rewritten maint, so rather than messing
up by rewriting it again (to its old
On 02/25/2013 09:14 AM, Peter Rosin wrote:
On 2013-02-23 19:06, Stefano Lattarini wrote:
On 02/23/2013 06:46 PM, Stefano Lattarini wrote:
On 02/21/2013 04:06 PM, Stefano Lattarini wrote:
In a couple of days, I will proceed with this branch moving:
* branch-1.13.2 - maint
* maint -
On 02/23/2013 07:06 PM, Stefano Lattarini wrote:
In a couple of days, I will proceed with this branch moving:
* branch-1.13.2 - maint
* maint - master
* master - next
Done.
Damn, not really. For some questionable reason, Savannah is rejecting
my non-fast-forward push to master
Just that by far the most common branch setup in git repos seems to be
using master as the dev trunk, with releases, release candidates
(etc) on special branches. There are often additional feature
branches for even more speculative changes, but master is generally
not really safe, even if it's
