>________________________________ > From: Benedikt Ritter <benerit...@gmail.com> >To: Commons Developers List <dev@commons.apache.org> >Sent: Thursday, 26 July 2012 3:28 PM >Subject: Re: [chain2] serialVersionUID > >2012/7/26 sebb <seb...@gmail.com>: >> On 26 July 2012 18:29, Brent Worden <brent.wor...@gmail.com> wrote: >>> On Thu, Jul 26, 2012 at 3:48 AM, sebb <seb...@gmail.com> wrote: >>>> On 25 July 2012 07:54, Jörg Schaible <joerg.schai...@scalaris.com> wrote: >>>>> sebb wrote: >>>>> >>>>>> On 24 July 2012 09:11, Jörg Schaible <joerg.schai...@scalaris.com> wrote: >>>>>>> Hi Elijah, >>>>>>> >>>>>>> Elijah Zupancic wrote: >>>>>>> >>>>>>>> Thanks Jörg! >>>>>>>> >>>>>>>> It sounds like we will need to change them all in chain because we >>>>>>>> have changed the package name. >>>>>>> >>>>>>> Well, since they are all different objects now, the Java runtime will >>>>>>> not >>>>>>> try to match them anyway, so it is for this special case not really >>>>>>> required. >>>>>> >>>>>> +1 >>>>>> >>>>>> >>>>>>> However, if you consider a change, I'd like to propose to use everywhere >>>>>>> a constant that reflects the day of change: >>>>>>> >>>>>>> servialVersionUID = 20120724L; // format YYYYMMDD >>>>>>> >>>>>>> It's easier then to keep track of changes. >>>>>> >>>>>> +0 >>>>>> >>>>>> Ideally the svuid is only changed when necessary. >>>>>> I don't think the id should be updated just because a new method was >>>>>> added, or code was updated. >>>>>> >>>>>> The danger with using the date is that maintainers may update the id >>>>>> whenever the source is updated. >>>>> >>>>> I did not say that. >>>> >>>> I know; but the fact that the id is a date may (mis)lead maintainers >>>> into updating it too often. >>>> >>>> If we do decide to use the day, maybe it should have a comment such as: >>>> >>>> // YYYYMMDD date of last change to serialized form. >>>> >>>>> - Jörg >>>>> >>> >>> Since the serialized form will never change without a release, the >>> svuid could also be aligned to the component version. >> >> Yes, but the same issue applies: it may not be necessary to change the >> svuid for each new version. >> This is particularly true of patch releases. >> > >I really don't see an issue here. People who have commit access know >what they do and their commits get reviewed by the ML. People who >don't have commit access will get a double review. First from the >person who applies a patch and then from the ML. I like Jörgs approach >(and I have adopted it for my work). > >Benedikt
Hi all, I'm no specialist in Java serialization, but I have one question (that may be stupid so I apologize in advance :-) about using a date as svuid. Say that someone from Japan (GMT +9) commits a class to [functor] using svuid 20120727 at 00:30 AM. Then some 12 hours later I (based in Brazil, GMT -3) find a bug in his class, modify a field or move the class to some other package. Then I would have to update the svuid, but as in my current timezone the svuid is 20120727 too, I would have to take some action, like waiting until the next day, increase the time precision (+ timezone?) or ask here in the mailing list for help. What would be the correct action in situations like this? And as I'm very lazy, I really like using the Eclipse feature to generate the svuid automagically (I believe it uses JDK serialver tool), but with some practice I could get used to using any other standard adopted by a project too :-) Just my 0.02 cents. Hope that helps. -Bruno > >>> Thanks, >>> >>> Brent >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > > > > Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
