I agree with this. I am in a situation where I don't install rsync myself, I have to depend on sysadmins to do it. They get very nervous and insist on installing it as something like "rsync2_5_5" because they are afraid some other users "legacy" rsync invocation is going to break; you can't blame them for their circumspection.
They'll gladly install bug fixes, of course, but I can't say every few months "hey could you install the new rsync" because there's a critical bug fix tied in with a bunch of features any current user is unlikely to use. I'm sure just getting them up to 2.5.6 from 5.5 will be a bit of a pain. If I really NEED a new feature, but frankly between perl and the three hundred or so options that rsync now supports that seems unlikely, then I can petition them to do the upgrade; otherwise, why should they? Dave > -----Original Message----- > From: Green, Paul [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 28, 2003 8:14 PM > To: Rsync Mailing List (E-mail) > Subject: Proposal that we now create two branches - 2_5 and head > > > I'd like to suggest that this is now a great time to create > two separate cvs > branches for the rsync product. One, which I'll tentatively > call 2_5, would > hold the version of the code that has been released to the > world as 2.5.6. > The other, which I'll tentatively call head, would hold the > development > activity leading up to the next field release. I'm not bound > to these names, > but I picked ones that are parallel to the names used in the > samba tree, for > simplicity and ease of communication. > > I won't go into a long involved explanation, because I think > most people > understand the tradeoffs. Briefly, I see the major benefit > as giving us the > ability to send out important bug fixes or security fixes to > users of 2.5.6 > without exposing them to experimental or lightly tested development > activities. I think splitting the branches will also let us > be a little more > experimental in the development branch, at least until we get > near the next > release phase, because we'll always have the field release in > which to make > crucial bug fixes available quickly. > > It is a little more work for the maintainers, but I think the > benefits far > outweigh the costs. We can minimize the extra work by > minimizing the changes > to the released version. And if we can get agreement to do > it, now is the > best time, when there has just been a release. > > Comments? > > Thanks > PG > -- > Paul Green, Senior Technical Consultant, Stratus Computer, Inc. > Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. > > > -- > To unsubscribe or change options: > http://lists.samba.org/mailman/listinfo/rsync > Before posting, read: > http://www.tuxedo.org/~esr/faqs/smart-questions.html > -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
