I'm fine with changes occuring in master; I'm hoping to merge back into master in another couple of weeks.
With Tapestry's fine granularity, it is likely that changes in my branch will not intersect changes for other localized changes. Things are very unstable in the 5.4-js-rewrite branch; tests fail, etc. It was still a conscious choice to use a feature branch for these changes, even knowing that I may have a difficult merge ahead. In general, I don't do that. Part of the cost is that I have a number of bug fixes in 5-4.js-rewrite that I can't mark as fixed in 5.4 until after the merge. On Wed, Jul 25, 2012 at 7:10 AM, Thiago H de Paula Figueiredo <[email protected]> wrote: > On Wed, 25 Jul 2012 10:36:38 -0300, Massimo Lusetti <[email protected]> > wrote: > >> Besides the previous question I would like to propose the use of a >> work flow similar to git flow[1] or even try to adopt it directly... >> What do you think? >> >> [1] https://github.com/nvie/gitflow/ > > > +1 for gitflow. > > -- > Thiago H. de Paula Figueiredo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
