continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <tryg...@apache.org>
Subject Re: [vote] merge id-refactor branch changes
Date Mon, 29 Jan 2007 13:40:56 GMT
Christian Edward Gruber wrote:
> Um, 1.0 to 1.1 seems like the right time to break an api if you are
> going to eventually.  Better if it were a 1.x to 2.x, but certainly it's
> not a 1.0.12 to 1.0.13 situation.  I think it woudl be hard to argue on
> a purely needs basis.  Apache as a whole is approaching 500,000 commits
> in their subversion repo over its lifetime, which couldn't amount to
> more than 4x results in any table, could it?  What are the real
> characteristics of how many keys are generated given a repo of a certain
> size, etc?   

1.0 to a 1.1 is not the time when you break an API. You can add stuff 
with minor released, but not break things. This is the versioning 
conventions used for all Maven-related projects. Perhaps trunk should be 
2.0, but as long as it's 1.1 it can't break the API.

I didn't understand the last part of your paragraph WRT to the Apache 
svn repository, please clarify it if I missed your point.

> Besides, the database will be broken and need migration or re-building
> between 1.0.3 and 1.1 anyway, so that's no barrier.  If we're running
> 1.1-SNAPSHOTs, well, guess what... they're snapshots - not guaranteed to
> function the same upon release.   Not reasons to do it, mind you, just
> rebuttals to some reasons to not do it. 

That is really not relevant in this case. We're talking about the 
external API for applications, not the database. Running a tool to alter 
the database is fine.

--
Trygve

> 
> Christian.
> 
> 
> Trygve Laugstøl wrote:
>> Rahul Thakur wrote:
>>>>> 'int' ids are now converted to 'long' across the project and to
>>>>> allow really large values. This should cater to scenarios where the
>>>>> id generation could be started from an arbitrary large value.
>>>> Won't this break the API?
>>> Yep, it would.
>>>
>>>> What is the use case where 4 billion IDs isn't sufficient?
>>> 2 billion you mean :-). But this also more of something that I have
>>> noticed  'traditionally' that ids are specified as long and stored as
>>> bigints in database
>> No, 4 billion. an int is +-2billion. Anyway, just because longs are
>> more traditionally used that is not a good enough reason to switch to
>> longs and break the API to me.
>>
>> -- 
>> Trygve
>>
> 
> 


Mime
View raw message