Proposal that we now create two branches - 2_5 and head
Madole, Dave BGI SF
Dave.Madole at barclaysglobal.com
Thu Jan 30 12:44:32 EST 2003
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
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
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
or so options that rsync now supports that seems unlikely, then I can
them to do the upgrade; otherwise, why should they?
> -----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
> 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.
> 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:
> Before posting, read:
More information about the rsync