Christian Edward Gruber wrote:
Trygve Laugstøl wrote:
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
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
Rahul Thakur wrote:
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,
Trygve Laugstøl wrote:
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.
[snip]
Can you please come up with a realistic use case where IDs would start
on something other than 0 or 1? The database is controlled by
Continuum and is an internal thing which we have complete control over.
I don't have a specific use case for Continuum handy, but I guess
Continuum can
[snip]
Can you please come up with a realistic use case where IDs would start
on something other than 0 or 1? The database is controlled by
Continuum and is an internal thing which we have complete control over.
I don't have a specific use case for Continuum handy, but I guess
Continuum can
ah, I forgot mine...
Here's my +1
Rahul
Christian Edward Gruber wrote:
+1
Rahul Thakur wrote:
Hi,
I'd like to request a vote to merge the id-refactor branch changes.
'int' ids are now converted to 'long' across the project and to allow
really large values. This should cater to scenarios
