I see some are trying to spread quite some FUD. Pierre Smits
*OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Wed, Nov 25, 2015 at 11:47 PM, Sam Ruby <ru...@intertwingly.net> wrote: > On Wed, Nov 25, 2015 at 5:18 PM, Greg Stein <gst...@gmail.com> wrote: > > On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby <ru...@intertwingly.net> > wrote: > > > >> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein <gst...@gmail.com> wrote: > >> > > >> > Don't shut down trunk/master for product development. > >> > >> I don't believe you heard my point, but I'm not going to repeat it. > > > > I read your post several times, completely :-P ... I just think it didn't > > argue against RTC being a form on control. (and yeah, maybe you weren't > > trying to argue that?) > > I don't believe that RTC is a form of control over others. I believe > that RTC is a mechanism to ensure that every change is adequately > reviewed. > > >> Instead I will add a new point. > >> > >> 'trunk/master for product development' is not the only development > >> model available to a project. As an example, I've seen models where > >> 'trunk/master is for product maintenance', and all development occurs > >> in a branch explicitly designated as where work on the next release is > >> to occur. > >> > > > > I think that is just playing with names. In Apache Subversion the > "product > > maintenance" is branches/1.8.x and branches/1.9.x (1.7.x and prior are > > deprecated). trunk is for "next release". > > > > In your naming model, where we've seen the name "develop" for "next > > release" (aka where all new dev occurs), then I'd say making it RTC is > > harmful. > > > > trunk/master was shorthand for "where dev occurs". If you want to use a > > different name... okay. :-) > > I don't believe it is just playing with names. There are projects in > when all non-trivial development occurs in feature branches. > > > Cheers, > > -g > > > > ps. fwiw, trunk/tags/branches isn't mandated in svn either. It was just > an > > ad hoc template we came up with back near the start of the project. We > > assumed third-party tools would focus around that naming, which is > > generally true, but svn itself has never cared. > > Ack. > > - Sam Ruby > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >