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