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 >> 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
