>>>>> Alexis <[email protected]> writes: > the way I understand git-flow is that for frequent pre-releases the > release branches are used, so master always points to the last stable release, > currently this would be release/3.1.0 (created from the v3.1 tag).
> As development on 3.1.1 begins a branch named release/3.1.1 is created from > next, and as development on next comes along every 'stable' state (meaning > all the tests run) of next is merged into release/3.1.1. > Once the official 3.1.1 version is tagged and released the release/3.1.1 > branch is merged into master and the release/3.1.1 branch becomes 'stale' > and only important bugfixes are merged into it from that point on. > How does this sound? Yes, I understand that, what I mean is perhaps as we move along during the development of 3.1.1, we also put out quick releases of 3.1.1.1, 3.1.1.2, etc. These wouldn't necessitate creating a new release branch, but would rather be interim merges of release/3.1.1 into master, plus a tag. This way, people consuming from master don't have to wait very long. My only fear with git-flow is that if master gets really slow (say, a release every few months), either people will think the project has stagnated, or everyone will switch to cloning from 'next', and then our work to maintain the integrity of 'master' won't mean a whole lot (which is what happened last time). We need to keep all the branches relevant to the users who track them. John -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
