On 26.08.2015 15:56, Vladimir Ozerov wrote: > One more important thing here - distinction between overall compatibility > and module compatibility. We may face serious bugs which severely affects > single module/subsystem and fix will break backward ocmpatibility only on > of that module. > E.g. currently in IGFS file might be locked for write forever in case of > abrupt shutdown of a node from which this write were initiated. The only > way to fix this reliably is to change an object which travels over a wire, > what might break backward compatibility. > > May be we should be able to relax compatibility requirements on module > level sometimes?
It's better to have the same kind of versioning rules for the wire protocol, too; a capability discovery can tell you when you can use a new kind of message. I don't know how important this kind of compatibility is for Ignite; it's extremely important in Subversion, because it allows independent updates/rollbacks of servers and clients. Or you can avoid the compatibility issue by calling the fixed protocol Ignite 2.0. :) -- Brane On Wed, Aug 26, 2015 at 10:40 AM, Branko Čibej <br...@apache.org> wrote: >> On 26.08.2015 08:54, Alexey Goncharuk wrote: >>> This particular change does not break the compatibility (a new method is >>> being added to the public API), however I am +1 for adding these >> principles >>> to the dev documentation. >> Way back when Ignite was still a podling I pointed out this: >> >> http://apr.apache.org/versioning.html >> >> >> http://subversion.apache.org/docs/community-guide/releasing.html#release-compat >> >> As I did then, I suggest we either refer to these docs directly, or copy >> over essentially the same principles to our docs. >> >> -- Brane >> >> >>> 2015-08-25 23:44 GMT-07:00 Konstantin Boudnik <c...@apache.org>: >>> >>>> Reading this I thought it would be a good idea to articulate some of the >>>> possible challenges that we will face in the future. >>>> >>>> Say, how we add/release incompatible changes like API modifications, >>>> deprecations, etc. Say, introduction of incompatible changes shouldn't >> be >>>> done >>>> in minor release of a project: Scala "transition" 2.9 -> 2.10 comes to >>>> mind as >>>> a biggest screw-up of the kind. Hence, to avoid being a laughing stock >> of >>>> the >>>> world's developers it would makes perfect sense to have some of these >>>> seemingly obvious principles either written or referred among other >>>> development resources. >>>> >>>> Thoughts? >>>> Cos >>>> >>>> On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote: >>>>> Ken, I added comments to the pull request on GitHub. >>>>> >>>>> I would prefer another committer to review this pull request as well >>>> since >>>>> public API is being changed (Dmitriy, Yakov?) >>>>> >>>>> -- >>>>> AG >>>>> >>>>> 2015-08-25 22:53 GMT-07:00 Ken Cheng <kcheng....@gmail.com>: >>>>> >>>>>> Hi Devs, >>>>>> >>>>>> Anybody can help me to do a code review for PR >>>>>> >>>>>> https://github.com/apache/ignite/pull/35 >>>>>> >>>>>> Thanks, >>>>>> kcheng >>>>>> >>
