Hi Elijah, > I think that the date can work because we rarely update the ids.
+1 > 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? not required IMHO, it can stay as you already modified them - maybe just put a note/comment as a reminder for future committers. As a 0.02 cents margin note: there are better serialization methods in the place of default Java serialization, guess who's still using that last one... -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jul 26, 2012 at 9:16 PM, Elijah Zupancic <eli...@apache.org> wrote: > @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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
