We also need to worry about stability too. We have a lot of changes in the
tree that are untested and we don't have any automated testing to verify all
the changes we have already made to the Apache tree don't have any hidden gems
(bugs). There has to be a balance with breaking compatibility moving forward
and having a stable code base.
APIs are something that should be very stable since it requires real work
(human time) to make the change. Files that can be blown away and recreated
over time should be considered less important. I don't think we need to have a
major version number bump for files, but we do for APIs breaking.
I haven't seen many requests for caches over 512GB per server. I think it is
important to have this change, more for partitions sizes and the potential to
reduce the number of partitions (reduces the seeking for writes).
For the first release I would like to see less changes so we can move over to
it quicker within Yahoo!. If we try to push to much into the release we are
going to have a harder time moving over to the Apache tree.
-Bryan
On Nov 25, 2009, at 2:25 PM, Leif Hedstrom wrote:
> On 11/25/2009 03:12 PM, John Plevyak wrote:
>>
>> Good point. So non-virtual functions which would imply wrapper objects
>> for internal objects with virtual functions. I wonder if there are any tools
>> to automate that.
>> Sigh. This is getting complicated. C++ is a pain. Makes me think the C
>> API isn't so bad.
>
>
> An important goal for our first ASF release ("v2.0") needs to be to freeze
> anything in APIs and ABIs that would otherwise break backward compatibility.
> Within the v2 release cycles, we can not break APIs or ABIs (IMO at least).
> Since we have no compatibility issues to deal with right now (since there has
> been no release yet :), now is the time to figure out as much as we can for
> changes that could break compatibility.
>
> This should include changes in the core too, like the cache dirent changes
> John is doing (now is definitely the time to do that, so people don't have to
> worry about nuking their caches when upgrading to a newer TS relase).
>
> So, lets keep the discussions open. I'd urge that we start Confluence Wiki
> pages for all major code changes that would change internals like this. I'll
> start one for the Remap plugin APIs once I get the time to work on that
> (hopefully in a week).
>
> Cheers,
>
> -- Leif
>
