On Tue, 12 Sep 2006, Frederik Holljen wrote:

> On Tuesday 12 September 2006 18:00, Derick Rethans wrote:
> > On Mon, 11 Sep 2006, Frederik Holljen wrote:
> > > Author: Frederik Holljen
> > > Date: 2006-09-11 19:17:38 +0200 (Mon, 11 Sep 2006)
> > > New Revision: 3468
> > >
> > > Log:
> > > - Fixed bug #8990: ezcMail->messageID should be named ezcMail->messageId
> >
> > As this is basically a bug I think we should use the new @apichange so
> > that we can kill the old wrong name in the next major version here. I am
> > also not sure whether we should do this:
>
> I disagree. Bug fixing is not a good reason for breaking BC.

Ofcourse I wasn't suggesting that we break it now. But we do reserve 
major version numbers (1.y.z -> 2.y.z) for BC breaking. We discussed at 
the conference that if we find things that are breaking BC already we 
mark them with the "@apichange <desc>" so that we can clean them up *if* 
we bumb the major version number.

> 
> > > +++ trunk/Mail/src/mail.php       2006-09-11 17:17:38 UTC (rev 3468)
> > > @@ -50,10 +50,11 @@
> > >   *                                       The encoding of the subject.
> > >   * @property ezcMailPart           $body The body part of the message.
> > >   *
> > > - * @property-read string           $messageID
> > > + * @property-read string           $messageId
> > >   *                                       The message ID of the message. 
> > > Treat
> > >   *                                       as read-only unless you're 100% 
> > > sure - 
> > >   *                                       what you're doing.
> > > + *                                       what you're doing. Also 
> > > accessible through
> > > + *                                       the deprecated property 
> > > messageID.
> > >   * @property-read integer          $timestamp
> > >   *                                       The date/time of when the 
> > > message was
> > >   *                                       sent as Unix Timestamp.
> >
> > I don't see a good point for documenting deprecated things like this.
>
> It should definitely be documented since upgrading users might get confused 
> when they find that code that "should not be working" actually is. This is 
> exactly why we have documentation.

Yes, sure... It isn't a bad thing to do at all, however, i think we need 
to make it more clear, something like:

 * @property-read string           $messageId
 *                                       The message ID of the message. Treat
 *                                       as read-only unless you're 100% sure - 
 *                                       what you're doing.
 * @property-read string           $messageID
 *                                       Deprecated alias for the $messageId 
property.

regards,
Derick
-- 
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components

Reply via email to