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 <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 > >>>>>> > >> >
