I agree with the hotfix brunch. But isn't a feature brunch something like "new plugin-xyz"? And a release brunch is e.g. 2.3.17 or 3.0.0?
Johannes ################################################# web: http://www.jgeppert.com twitter: http://twitter.com/jogep 2014-02-06 9:33 GMT+01:00 Lukasz Lenart <lukaszlen...@apache.org>: > The only things that needs clarification is when to use > feature/support/hotfix prefix. > > - hotfix is obvious (I think) - security vulnerabilities > - feature - something big, like Struts2 for example :-) > - support - daily work with JIRA tickets? > > wdyt? Or I messed up everything :-) > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > 2014-02-06 Lukasz Lenart <lukaszlen...@apache.org>: > > git-flow applied! > > > > http://struts.staging.apache.org/git-for-struts.html > > > > Please check if everything os ok (I'm not sure what else I suppose to > > do instead calling git flow init -d) > > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > > > 2014-01-29 Lukasz Lenart <lukaszlen...@apache.org>: > >> Just added info about git-flow > >> > >> http://struts.staging.apache.org/git-for-struts.html > >> > >> 2014-01-29 Lukasz Lenart <lukaszlen...@apache.org>: > >>> 2014-01-28 Rene Gielen <rgie...@apache.org>: > >>>> 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. > >>> > >>> All these points are valid for git, but they don't proof that we must > >>> use the git-flow ;-) > >>> > >>>> 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. > >>> > >>> Ok, I'm still not fully convinced but it doesn't make sense to spend > >>> more time on this topic - let's adopt the git-flow! > >>> > >>> > >>> Regards > >>> -- > >>> Łukasz > >>> + 48 606 323 122 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
