> > Given that it is being done right now, experience shows that it is > > quite feasible > I totally disagree. The cleanup of base types has been postponed for (wow, it > is actually) years. This is stagnation. This is always a matter of someone having or wanting to spend the time. You could see it from the other way, that it was good enough to work for so long. That was the original plan. Calling this stagnation is not fair to the people that did spend work on it.
> Still don't get the point. As we are out of rolling releases, people don't > need > to update, they can stay on their current release. > It would be the same issue, if you delay this by two releases, at some point > one needs to stay on the current release, or update the code. Keeping compatibility windows longer allows for more flexibility on the other end. Again it’s a tradeoff between work on the maintainer and on the user side. > My point here is, don't over regulate the thing. If you are a 20 person > company, don't act like a multinational enterprise. Our working rules should > be adapted to our current situation, or the overhead is too big. That is why we are discussing it, or have discussed it. This is what came out of it. > > Which is why we need to implement on-the-wire conversions to allow for > > smooth transitions (for which a lot of work has already been done in > > RTT). Which would also give us full support for inheritance (as we > > would get subclass-to-superclass connections) and finally break the > > *need* for something like RBS in the first place. Kill two birds with > > one stone. > If this works out like the 'new release mechanism' we may not change any > code within the next 3 years ? Could we please try to improve the tone of the discussion? Cheers, Jakob _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
