On 20 May 2015 at 05:24, David Golden <x...@xdg.me> wrote: > Other development work can go live on devel (or topic branches) while we > wait for TRIAL releases to stabilize. > > I think this will be a good practice for the PTG in general. >
A problem I experience there is "master" is generally the branch people expect to file pull requests against. Do you want pull requests filed against last-stable? Or do you want them filed against the devel branch? Sure, you can set the default on github to be something other than master, and then people *should* get their fresh clones such that they track the "devel" branch by default instead of master, but you'll have annoying cases for people who already have forks/clones where master is still the default: Thus, the annoying workflow is: - clone - create branch - hack - test - commit - file pull request - not notice you pulled against a different branch - get confused why github says it wont merge - realise with horror master is not the default - go back to rebasing - realise a lot of things have changed and it doesn't even rebase cleanly - misc unfucking - force push That is, I think semantically, "master" and "blead" are similar, and assuming "master" to mean "stable" is a bit odd. I think its more natural in git terms to have a dedicated branch for stable release series, and have people not realise it exists, and have your proposed "devel" branch simply called "master". Though my thinking is obviously at odds with a lot of peoples here, its based on the idea that "master" is universally "the default branch" in Git. The default branch for commits and pushes and etc etc etc. Having to tell everyone using some mechanism that "the default" is not the regular default is just peculiar. Contributors shouldn't need to know about release engineering practices, and they should be able to just pull to master, and release engineering stuff should be isolated in its own branch. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
