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

[jw schultz]

On Wed, Jan 29, 2003 at 05:44:32PM -0800, Madole, Dave BGI SF wrote:
> 
> 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?

You bring up a good point Dave.  There is a great deal of
variety in how projects handle their version numbers.
We all know the linux numbering scheme, other projects
use a version.revision.patch where patch means only bug fixes.
Rsync seems to be neither of these.  In fact i'm not sure
what the criteria would be to go to 2.6.

Perhaps you'd like to distill from this thread and the list
a draft release version numbering philosophy statement.  
Gack! What a lousy title for a document, sounds like
something the PHBs would go for.

Although there were a number of enhancements going from
2.5.5 to 2.5.6 even i, who wanted my feature in a release,
consider it released primarily for the bug-fixes.  By August
there were just too many cases where bug reports were for
things that had already been fixed.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt