Re: Major package revisions

On Tue, 2002-10-22 at 18:42, Jon Parise wrote: > On Tue, Oct 22, 2002 at 06:50:13PM +0200, Martin Jansen wrote: > > > > I wasn't so much wondering about the packaging tools as I was curious > > > whether having Log 1.x and Log 2.x both listed on the package > > > information page would confuse things. I guess the Log 2.x version > > > would always be considered the "newest" and be offered by default. > > > > That's right ;-). Apart from changing the package information I don't > > see a good solution for this, unfortunately. > > I suppose one possible "solution" would be implementing a "branches" > system similar to Freshmeat's, but I doubt all that many packages > would really make use of it. Still, I wouldn't object if someone > were to implement such a feature. =) Actually, I think we can solve this in an (IMHO) easier way: There's a plan behind PEAR's version numbering scheme. The basic idea is that for bugfixes and minor releases, you change the "micro version" only (third number), for new but backwards-compatible functionality you increase the second number (minor version), and only for burning-bridges-non-BC revisions do you change the major version. This is our versioning scheme. Looking at how the installer works today, it should really not automatically upgrade to anything with a different major version number. That would introduce a branch concept in the sense that each major version would be its own branch. This does add an extra dimension (in addition to release state) to the process of suggesting versions to users, but that's manageable. - Stig -- Stig Sæther Bakken, Fast Search & Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb