Re: Re: deprecating

On 7/19/05, Joe Stump <joe@joestump.net> wrote: > Supposedly you can, but according to the RFC any change in the API > would require I roll out some other package (ie. Foo_Bar2). The > problem with this package is that 0.2 was released stable (evidently > before this RFC was accepted) and then magically jumped to 1.0.1beta. An API *change* is meant as something that breaks BC. An API *addition* is fine and does not break BC, therefore you don't have to release a new major version. Yes, this package has some version # problems, but it happens. We now have the RFC so this doesn't happen. > > Also, since when is deprecating something breaking backwards > compatibility? It would still function as it did before. And, if I > deprecate something going from 1.0 to 2.0 (but leave it there, while > changing all docs) why can't I remove it in 3.0? People would have > had an entire major point release to prepare for the change. Deprecating isn't breaking BC. As long as code written for a previous version will still work in the current version you're not breaking BC and therefore you don't need to have a new package. And again, the "new package for BC breaking" rule is non-negotiable. Please search the archives for BC, backwards compatibility, version, major version, etc. > > Also, if my API doesn't change do I still have to move everything > into a new package? Multiple new packages makes pretty much zero > sense - after all this is exactly what version numbering is for. You > should know that 1.0 and 2.0 have different feature sets without > having to install 14 different versions of the same package. I don't understand this question...if you don't change the API it's not breaking BC. A new feature should up the second #. I.e. 1.3.4 => 1.4.0 if you add a feature. > > A better approach, IMO, would be to have package.xml enable > developers to somehow warn a person about potential problems *before* > pear installed the new package. For instance, pear would notice that > I'm going from 1.0 to 2.0 and stop to tell the person upgrading that > upgrading will cause X, Y and Z to break and to update their code, if > needed, before installing. I would suggest that if you are maintaining BC then you should stay within the same major version # and only alter the second #. A new major version # should be a new package. If we do this for some releases but not others we're going to get into a mess where one package is: Package 2.0 and another is Other2 2.0. True, we have a few of these already, but we're trying to stop confusion and breakage. > > --Joe > > On Jul 19, 2005, at 10:15 AM, Joshua Eichorn wrote: > > > Lukas Smith wrote: > > > > > >> Joe Stump wrote: > >> > >> > >>> OK, > >>> > >>> On another note, what if I have an old package (I do) that has a > >>> function named foo_bar(). This package has only one stable > >>> release (0.2) and one beta release (1.0.1beta). Can I deprecate > >>> foo_bar(), have it call fooBar() and then throw a notice that > >>> it's deprecated when it's used? > >>> > >>> If so, then how long do I have to wait to finally remove the > >>> deprecated function? One release? Two? > >>> > >> > >> > >> IMHO you cant deprecate a method inside a major version, since > >> that is effectively a BC break. > >> > >> regards, > >> Lukas > >> > >> > > You can still change the api in anything that hasn't has a stable > > release right? > > -josh > > > > -- > > PEAR Development Mailing List (http://pear.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Justin Patrin