@Benedikt - This reply isn't addressed to you I just replied to your message to continue the thread.
Wow, folks. I had no idea that the serialization id would be such a big deal. I jumped the gun and checked in ids done in the date format because it sounded like a good enough solution. I really don't have an opinion on what approach that we use as long as we all agree on it. I think that the date can work because we rarely update the ids. Furthermore, all that matters is that a given id has been incremented from the last id. In the end, I will change all of the ids to whatever format that we decide on. Do we want to have a vote or something about this? Thanks, -Elijah On Thu, Jul 26, 2012 at 11:52 AM, Bruno P. Kinoshita <brunodepau...@yahoo.com.br> wrote: > > >>________________________________ >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
