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 For additional commands, e-mail: dev-h...@struts.apache.org
