commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [chain2] serialVersionUID
Date Thu, 26 Jul 2012 18:12:59 GMT
On 26 July 2012 18:29, Brent Worden <brent.worden@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 3:48 AM, sebb <sebbaz@gmail.com> wrote:
>> On 25 July 2012 07:54, Jörg Schaible <Joerg.Schaible@scalaris.com> wrote:
>>> sebb wrote:
>>>
>>>> On 24 July 2012 09:11, Jörg Schaible <Joerg.Schaible@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message