I vote for gitflow. It's simple and straight forward. On Tuesday, January 28, 2014, Rene Gielen <rgie...@apache.org> wrote:
> Am 28.01.14 12:19, schrieb Lukasz Lenart: > > I don't think we need git-flow - we don't have huge development team, > > there is (almost) no situation when we work together on some > > issue/feature. And learning the whole flow is useless (at this > > moment). > > > > Then I'm wondering a bit why we wanted to move to git in the first > place. It was my impression that we wanted to profit especially from > advanced processes like easy feature branching and merging, e.g. > - isolate features to make their impact better assessable > - allow for (yet not require!) code reviews before features are merged > to mainline - especially useful for our new committers, IMO > - allow cherry picking for releases > - backporting features from development to stable branches > - allow for collaborative working on groundbreaking features and ideas > for new major versions > - allow isolated work and straight forward, well documented processes > for hotfix releases, including multiple merging to all working branches > - allow for external contributions while working on new features, solely > targeted towards such feature > ... to name just a few. > > As for me, I did not find it hard to learn git-flow to a level that I > felt my own and my team's productivity increased. I started with forcing > myself to work based on feature branches and the follow-up processes, > only to to find me loving it soon and missing it everywhere where I was > forced to use e.g. svn where such processes are PITA. > > > I'd rather start with something simpler and what we can understand and > > explain each others - using git-flow means we must understand how it > > works in first place and it isn't just to read some blog posts - > > understand the whole philosophy behind. > > > > I agree that git-flow is not the only possible way to go, and that we > might want to establish our own solution. Of course, it is well thought > out and flexible for both keeping things simple if you want to, as well > as offering advanced tooling for advanced problems. In either case - > adapting git-flow or working out our own process - I would opt for a > model that is both easy to use and grows with our needs. I see advanced > needs if we start our work on S3, and if we might manage to attract more > contributors along the way. Certainly we would want to establish a flow > that does not limit ourselves in future, wouldn't we? > > Just to give an example, I started some prototyping experiments on how > multiple possible return value types and result containers could work > out (inspired by Spring MVC and Play). To advance on this, I would like > to share this and have others review and potentially collaborate on > this. But for a rather long time, this might stay experimental and not > ready even for development branches that we might want to offer > adventurous users to use in their projects. I'm pretty sure that there > might be a lot of such experiments and ideas that develop around the > idea of bringing out a new major release. > > > That being said, I opt to work out our own flow - simple and straight > > forward. There can be advantage - we must adjust our release process > > to the flow as well. > > > > > > Regards > > > > -- > René Gielen > http://twitter.com/rgielen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@struts.apache.org <javascript:;> > >
