Re: [vote] merge id-refactor branch changes
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 it can't break the API. Well, in the Java world, this convention (While good) is not very well followed. I agree, however, that 1.1. should be backwards compatible in a good versioning system, so I support your notion that trunk should be 2.0. I think there is enough change that is substantial enough in operation and features that 2.x is probably a more useful description. This isn't a small increment in functionality. It is the standard we've been following for years. IMO there isn't a whole lot of features, just a bunch of (very useful) enhancements. To me there is no reason to break the existing API as from what I can tell there haven't been any fundamental changes in the APIs and concepts on how Continuum works. This is in no way meant as a critique to all the hard work all the guys has been putting in Continuum. I've heard nothing but good stuff from all the people I have gotten to try out Continuum trunk, many who are still running it in production. I thank all of you for your hard work! -- Trygve
Re: [vote] merge id-refactor branch changes
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
Re: [vote] merge id-refactor branch changes
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, 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. Yep, I know, I was referring to the +ve 2 billions. I could say a case where Id generation could be set to start from a fairly large value and so are the Id sequence increments. One could argue this is an edge case ;-). 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. IMHO the version change to 1.1 is a fair indication that the API might have changed. Having said that, I will go with whatever most of us think sounds practical :-) The only thing you can do is to add stuff, not break existing code. -- Trygve
Re: [vote] merge id-refactor branch changes
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. Well, in the Java world, this convention (While good) is not very well followed. I agree, however, that 1.1. should be backwards compatible in a good versioning system, so I support your notion that trunk should be 2.0. I think there is enough change that is substantial enough in operation and features that 2.x is probably a more useful description. This isn't a small increment in functionality. Christian. -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
Re: [vote] merge id-refactor branch changes
[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 be used in other products/projects. Not sure I understand what you mean that the database is controlled by Continuum? IMHO the version change to 1.1 is a fair indication that the API might have changed. Having said that, I will go with whatever most of us think sounds practical :-) The only thing you can do is to add stuff, not break existing code. Ok, agree on this one. Breaking API changes should be a change in major version. -- Trygve
Re: [vote] merge id-refactor branch changes
[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 be used in other products/projects. Not sure I understand what you mean that the database is controlled by Continuum? IMHO the version change to 1.1 is a fair indication that the API might have changed. Having said that, I will go with whatever most of us think sounds practical :-) The only thing you can do is to add stuff, not break existing code. Ok, agree on this one. Breaking API changes should be a change in major version. Cheers, Rahul -- Trygve
Re: [vote] merge id-refactor branch changes
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 where the id generation could be started from an arbitrary large value. Cheers, Rahul
