Proposal that we now create two branches - 2_5 and head

[Madole, Dave BGI SF]

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:Paul.Green at stratus.com]
> 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
>