Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On 20 Mar 2003 13:29:09 +0000, Anthony Williams <anthony.williamsNOSPAM at anthonyw.cjb.net> wrote: >Consequently it would be nice to have say 2.0 and 2.1 run on separate >branches, with 2.1 containing new features, and the 2.0 branch restricted to >bug fixes. The decent branching support is one of the key benefits of CVS IMO >--- I just did a bugfix branch for a project using VSS the other day, and then >had to merge the changes back into the mainline; it is a *PAINFUL* process, >one file at a time, which took me all morning (only 300 files). Ouch. We do this every couple of days here from release to development.. one person, 10 minutes. That is one of the strengths of cvs, and I know I should use it... just bad habits I guess - I tend to keep two sandboxes and flip between them. >Labelling releases as "stable" seems like a good plan, too, so people who want >minimal hassle, but are willing to accept fewer features, can download (say) >2.0.9, whereas those who want the new features but accept that things might go >wrong every now and again can get 2.1.3. I've thought of this. The 'stable' branch would have to be bug/security fixes only otherwise it'll just get out of sync. Then of course you get in to the 'is it a bug or a feature request' ambiguity that we frequently get here (eg. customer needs feature A, which works one way, to work differently. They claim it's a bug (so they don't have to pay for the work), and we say otherwise...). If I can definately lock down the stable branches so they truly are stable, then it would seem to be the best way to go forward. >Of course, there's then the issue of how many old versions to maintain >bugfixes for --- I can't believe that every bug in 2.0 will be fixed before >you've added new features that aren't in 2.1, and consequently released 2.2 >(if you followed my suggested numbering scheme) given the rate at which >features seem to get added to CVSNT. I suppose that's why the major software >vendors just give up and say "you've got to upgrade to V8.2 if you want the >fix, despite the fact that you only need the features of V2.1" --- they can't >be bothered with the hassle of maintaining old releases, and forcing people to >upgrade is a revenue generator anyway. I probably wouldn't support much further back than the last stable release... even now I prefer people to upgrade if they're having problems, because there are so many little fixes go in it's quite likely that their issue has already been solved. I know they support old releases in Linux (the 2.0.x kernels are still supported) but that's because they have separate people doing each branch, so it scales a lot better. Tony