Re: Re: cvs: pear(MAINT_1_1) /Net_NNTP package.xml

Greg Beaver wrote: > Heino H. Gehlsen wrote: > >>heino Tue Nov 29 19:52:49 2005 EDT >> >> Modified files: (Branch: MAINT_1_1) >> /pear/Net_NNTP package.xml >> Log: >> Prepare for release 1.1.3 (beta) - update > > > This HAS to stop Heino, you can't maintain 3 copies of the same damn > program in PEAR. > > For the uninitiated, version 1.0.x is stable, version 1.1.x is beta, and > version 1.2.x is alpha. > > Stop being such a male and commit to an API. Maintaining duplicate > packages in PEAR is expressly forbidden, and certainly maintaining 3 of > the same package using branches and preferred_state is just loopy. Then this rule should be adjusted in my eyes. It makes full sense to me likt it makes sense having PHPUnit and PHPUnit2. Why not have a stable 1.0.x and a stable 1.1.x at the same time? Makes absolutely sense in terms of configuration management. I and certainly a lot more people would sleep a lot better if we had that even for PHP itself. Having a PHP 5.0.x and PHP 5.1.x running parallel (like we still have PHP 4.4.x, which is 4.3.x + BC-breaking bugfix introduced in 4.4.0 requiring the step from 4.3.11 to 4.4.0) would make life much easier for a reasonable number of developers, qa engineers and IT managers. Well. We don't have that and that's OK, that's non-company backed open source and I know only a handful of non-company backed OSS that have config management processes at all. What I want to say: If someone is willing to do the work of maintaining different stable trees of the same software, why would you want to stop him from that? Heino should be encouraged to continue his work and hopefully other OSS developers adopt that. That's nothing new and special, most Linux distributors do it in some way: Regualary a release "Wackelwurm Linux 3.0" is fixed to "Somesoftware 1.3". Even when "Somesoftware 1.3" is stopped being maintained and "Somesoftware"-Developers only fix bugs in "Somesoftware 1.4", Linux distributors backport these fixes in "Somesoftware 1.3". Everyone for himself of course. Would be possible to have those developers capacities focused on keeping "Somesoftware 1.3" maintained as long as possible, would'nt that be great? I think yes, so my request is here to adjust/clarify that rule to allow multiple (even stable!) versions of the same package in PEAR. The PEAR installer needs to be able to distinguish between bugfix-, feature- and incompatibility-releases to make that usable but that should be possible. Sebastian