Hi, I understand the reasoning behind the social convention of the master stabilisation period but what seems to be evolving as git standard is that master should always be stable / releasable - not stable, but something that can be relied upon. From where we are the equivalent is not to push stabilisation into a branch but to have it more release-ready by default.
The concern about people not sharing what is being worked on and large changes coming out of nowhere are, in my opinion, a communications issue and not a source control issue. Having partially completed features on master or changes that are "temporary" awaiting the rest of the work is worse than having more branches. I don't mean to say that branches should be needed for every change - that is why the develop branch in GitFlow exists to allow the small features and fixes to work on the mainline without affecting the stability of master. Developers may indeed switch everything to develop - but I don't see how that leads to confused newcomers. A standard tenet of git is that you don't commit directly to master and branching is part of the workflow unlike CVS or SVN. This allows easy tracking of 2 different targets: Latest stable version (master) and latest completed features (develop) and work in progress is elsewhere. Whilst I can't argue with the simplicity of our branching model I don't know that I completely agree that stopping for a month every release is indicative of a good process... Andy On Sun, 23 Jul 2017 at 03:32 Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 22 Jul 2017 21:22:43 +0000 Andrew Williams <a...@andywilliams.me> > said: > > > Hi eflers :) > > > > So after thinking about issue management and planning milestones I > thought > > more about our source control. We currently have various different models > > used but the bottom line is that it all hits master all the time which > can > > lead to less stability than ideal and also makes stabilisation windows > > critical to enforce. > > > > As a suggestion I think we should consider agreeing on a singlet > branching > > model and I'd recommend GitFlow (described quite well here > > > https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow > ). > > As well as being well organised there is a solid gitflow plugin that > helps > > to manage branches and workflows. > > > > Bottom line: main development moves from "master" to "develop" and master > > then remains the most recent release (always stable ;) ). Releases then > are > > created on a branch rather than being branched after release. > > > > This correlates well with the proposed phab task management - a release > > milestone branches off develop as we prepare to release like current > > stabilisation. Big feature tasks branch off develop as a feature branch > and > > the task describing it can be marked resolved when it merges in. Hotfixes > > merge into develop and master which makes it easier to ensure we don't > > forget to backport fixes :). > > > > Let me know what you think - it's worked quite well in previous groups > but > > I appreciate it may not for us and I expect there are a lot of > experiences > > here that could feed in :) > > this imho creates an unnecessary branch. if you want releases to branch off > they can just branch early BEFORE release from master, stabilized, then > tag at > release. there's no need for a develop branch. > > the point of stabilization in master is a social thing. it's trying to > force > people into helping with stability and bugfixing. telling them "stop all > your > feature work and help with this". it is MEANT to be an inconvenience to > try and > engineer this kind of behaviour. i know it doesn't 100% work, but it does > have > an effect. by just pushing all of that off into a branch, we'll basically > lose > almost all of any positives we get from that. > > developers have always been free to do major work in a branch. the > downside of > this is no one knows it's happening until suddenly it all lands and all > hell > breaks loose. sometimes it's necessary. sometimes it's not. > > what is going to likely happen is everyone just switches to develop branch > - > anyone wanting to track development is unaware of this and sees a stale > master > branch and can't find where development is happening and we have really > done > nothing positive - just added layers for hiding. > > i like the simplicity of our model and that it pushes our current state of > development right as the first thing into the public with no extra work, > and > that it tries to keep everyone on the same page as much as possible and > tries > to pull everyone together for releases. > > > Happy weekend, > > Andy > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
