Re: [DiSCUSS] Incompatible changes
Yup, big +1's on both points: the versioning schema (thanks a bunch for digging it up, Brane!) and sticking to a stricter compatibility rules. Integers are cheap and abundant, but conveying the clear message that say 2.0 isn't compatible with 1.4 because of XYZ in hadoop module is important. It is a far clearer than "2.0 and 1.4 are fine, except that hadoop module isn't because of XYZ". Regards, Cos On Wed, Aug 26, 2015 at 07:35PM, Branko Čibej wrote: > 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 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 : > >>> > 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 : > > > >> Hi Devs, > >> > >> Anybody can help me to do a code review for PR > >> > >> https://github.com/apache/ignite/pull/35 > >> > >> Thanks, > >> kcheng > >> > >> >
Re: [DiSCUSS] Incompatible changes
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 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 : >>> 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 : > >> Hi Devs, >> >> Anybody can help me to do a code review for PR >> >> https://github.com/apache/ignite/pull/35 >> >> Thanks, >> kcheng >> >>
Re: [DiSCUSS] Incompatible changes
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? Vladimir. On Wed, Aug 26, 2015 at 10:40 AM, Branko Čibej 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 : > > > >> 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 : > >>> > Hi Devs, > > Anybody can help me to do a code review for PR > > https://github.com/apache/ignite/pull/35 > > Thanks, > kcheng > > >
Re: [DiSCUSS] Incompatible changes
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 : > >> 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 : >>> Hi Devs, Anybody can help me to do a code review for PR https://github.com/apache/ignite/pull/35 Thanks, kcheng
Re: [DiSCUSS] Incompatible changes
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. 2015-08-25 23:44 GMT-07:00 Konstantin Boudnik : > 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 : > > > > > Hi Devs, > > > > > > Anybody can help me to do a code review for PR > > > > > > https://github.com/apache/ignite/pull/35 > > > > > > Thanks, > > > kcheng > > > >
