I’ve created an umbrella ticket for REST https://issues.apache.org/jira/browse/IGNITE-3879 <https://issues.apache.org/jira/browse/IGNITE-3879>
And I wouldn’t deprecate anything until the next version gets released ;) — Denis > On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <skoz...@gridgain.com> wrote: > > Denis > > Generally I'm fine for your approach. I think for 2.0 (or may be for a next > 1.x minor version) we can note that currently REST API is deprecated. It > will allow us to replace REST by a new implementation once it will be done. > > On Fri, Sep 9, 2016 at 4:11 PM, Denis Magda <dma...@gridgain.com> wrote: > >> Sergey, >> >> I do agree with you that Ignite’s REST API implementation has to be >> revisited. Your concerns sound reasonable. But personally I wouldn’t rush >> trying to release it under 2.0 because NodeJS won’t be a part of this >> release while it can propose additional requirements to the next generation >> of REST API implementation. >> >> Does it make sense to you? >> >> — >> Denis >> >>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <skoz...@gridgain.com> wrote: >>> >>> Vova, >>> >>> There are more issues than processing (String, String) only: we can't >>> process JSON objects as values, current implementation doesn't follow >>> general RESTfull API requirements. >>> Moreover we're still have no connectors for PHP, Python and other popular >>> languages for web development of LAMP market and REST API is a single way >>> get access to Apache Ignite. >>> >>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <voze...@gridgain.com> >>> wrote: >>> >>>> Denis, >>>> >>>> Very good catch! Our REST API in ir is current appearance are virtually >>>> useless because it only operates on strings. We'd better to design the >> new >>>> one.with blackjack and etc.. >>>> >>>> On Fri, Sep 9, 2016 at 3:39 AM, Denis Magda <dma...@gridgain.com> >> wrote: >>>> >>>>> Basically, we can have two versions of the REST API if we want to care >>>>> about the compatibility and remove the old one (deprecated) at some >> point >>>>> of time. Moreover, NodeJS feature [1] can highly influence on the next >>>>> generation of our REST API implementation. So I wouldn’t introduce the >>>> next >>>>> version of REST API implementation before NodeJS component is done. >>>>> >>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961 >>>>> >>>>> — >>>>> Denis >>>>> >>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <skoz...@gridgain.com> >>>> wrote: >>>>>> >>>>>> I agree with Alexey. >>>>>> >>>>>> The key point is a chance to don't care for compatibility. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Sep 8, 2016 at 9:56 AM, Alexey Kuznetsov < >>>>> akuznet...@gridgain.com> >>>>>> wrote: >>>>>> >>>>>>> Just my opinion. If we move this to 2.1 that will result that we will >>>>> have >>>>>>> to support 2 versions of REST APIs. >>>>>>> In Ignite 2.0 we could break compatibility and redesign REST API from >>>>>>> scratch. >>>>>>> >>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dma...@gridgain.com> >>>>> wrote: >>>>>>> >>>>>>>> I would move it to 2.1 or 2.2. >>>>>>>> >>>>>>>> — >>>>>>>> Denis >>>>>>>> >>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan < >>>> dsetrak...@apache.org> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Sergey, I don't think we can fit redesigning of HTTP/REST into our >>>> 2.0 >>>>>>>>> release. The 2.0 already looks pretty packed. Perhaps we should >> plan >>>>> it >>>>>>>> for >>>>>>>>> the release after, like 2.1? >>>>>>>>> >>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov < >> skoz...@gridgain.com >>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I suppose we should redesign HTTP REST API. We've a dozen issues >>>>>>> around >>>>>>>> the >>>>>>>>>> REST implementation and the provided functionality is very limited >>>>> and >>>>>>>>>> doesn't follow last changes for Ignite. The most suitable ticket >> is >>>>>>>>>> IGNITE-1774 >>>>>>>>>> REST API should be implemented using Jersey >>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably >>>> we >>>>>>>> need >>>>>>>>>> to >>>>>>>>>> have a root ticket for that. >>>>>>>>>> >>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan < >>>>>>>> dsetrak...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0. It >> is >>>>>>>>>>> definitely an important release for us and good supervision is >>>> going >>>>>>> to >>>>>>>>>> be >>>>>>>>>>> very helpful. >>>>>>>>>>> >>>>>>>>>>> I have looked at the tickets and the list seems nice. I would >> also >>>>>>> add >>>>>>>> a >>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as well, >>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do >>>> it >>>>>>>> prior >>>>>>>>>>> to 2.0. >>>>>>>>>>> >>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793 >>>>>>>>>>> >>>>>>>>>>> D. >>>>>>>>>>> >>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dma...@gridgain.com >>> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Community, >>>>>>>>>>>> >>>>>>>>>>>> Let me take a role of the release manager for Apache Ignite 2.0 >>>> and >>>>>>>>>>>> coordinate the process. >>>>>>>>>>>> >>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be >> released >>>>> by >>>>>>>>>> the >>>>>>>>>>>> end of the year. This sounds like a good practice to make a >> major >>>>>>>>>> release >>>>>>>>>>>> once a year. I would suggest us following the same rule. >>>>>>>>>>>> >>>>>>>>>>>> Actual we have more than 3 month for development and I’ve >> prepare >>>>>>> the >>>>>>>>>>> wiki >>>>>>>>>>>> page that contains tickets that are required to be released in >>>> 2.0 >>>>>>> and >>>>>>>>>>> that >>>>>>>>>>>> are optional >>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/ >>>>>>> Apache+Ignite+2.0 >>>>>>>>>>>> >>>>>>>>>>>> Proposed release date is December 23rd, 2016. >>>>>>>>>>>> >>>>>>>>>>>> The tickets that are required for the release basically break >> the >>>>>>>>>>>> compatibility and we postpone fixing them in minor release or >>>> they >>>>>>>>>> bring >>>>>>>>>>>> significant improvements into the product. Please review the >>>> page, >>>>>>>>>>> provide >>>>>>>>>>>> your comments and assign the tickets on yourself if you’re ready >>>> to >>>>>>>>>> work >>>>>>>>>>> on >>>>>>>>>>>> them. >>>>>>>>>>>> >>>>>>>>>>>> — >>>>>>>>>>>> Denis >>>>>>>>>>>> >>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko < >>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> There is one more use case where several types per cache can be >>>>>>>>>> useful >>>>>>>>>>> (I >>>>>>>>>>>>> know that it's utilized by some of our users). The use case is >>>> the >>>>>>>>>>>>> following: transactional updates with write-behind and foreign >>>> key >>>>>>>>>>>>> constraints on the database. In case data within transaction is >>>>>>>>>>>> collocated >>>>>>>>>>>>> and all types are in the same cache, it works, because there is >>>>>>> only >>>>>>>>>>> one >>>>>>>>>>>>> write-behind queue. Once we split different types into >> different >>>>>>>>>>> caches, >>>>>>>>>>>>> there is no guarantee that objects will be written in the >> proper >>>>>>>>>> order >>>>>>>>>>>> and >>>>>>>>>>>>> that the constraints will not be violated. >>>>>>>>>>>>> >>>>>>>>>>>>> However, I think this is not a very clean way to achieve the >>>>>>> result. >>>>>>>>>>>>> Probably we should just provide better support for this use >> case >>>>> in >>>>>>>>>>> 2.0. >>>>>>>>>>>>> Basically, we somehow need to allow to share a single >>>> write-behind >>>>>>>>>>> queue >>>>>>>>>>>>> between different caches. >>>>>>>>>>>>> >>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>> >>>>>>>>>>>>> -Val >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan < >>>>>>>>>>>> dsetrak...@apache.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov < >>>>>>>>>> skoz...@gridgain.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Alexey >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You're right. Of course I meant growth of caches number. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I see a few points here: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. If a grid used by various applications the cache names may >>>>>>>>>> overlap >>>>>>>>>>>>>> (like >>>>>>>>>>>>>>> "accounts") and the application needs to use prefixed names >>>> and >>>>>>>>>> etc. >>>>>>>>>>>>>>> 2. For clear or destory caches I need to know their names (or >>>>>>>>>> iterate >>>>>>>>>>>>>> over >>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For >>>>>>>>>>> destroy/clear >>>>>>>>>>>>>>> caches belonging to same group we will do it by single >>>> operation >>>>>>>>>>>> without >>>>>>>>>>>>>>> knowledge of cache names. >>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be >>>> inherited >>>>>>>>>> by a >>>>>>>>>>>>>> cache >>>>>>>>>>>>>>> created in that group (like eviction policy or cache mode). >>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it >>>>>>> applicable >>>>>>>>>>> for >>>>>>>>>>>>>>> regular caches as well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as >>>>>>>>>> proposed >>>>>>>>>>>> by >>>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL >>>> schemas >>>>>>> due >>>>>>>>>>> to >>>>>>>>>>>> too >>>>>>>>>>>>>> many different caches. I think Sergi proposed a good solution >>>> for >>>>>>>>>> it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov < >>>>>>>>>>>>>> akuznet...@gridgain.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> How grouping will help? >>>>>>>>>>>>>>>> To do some operation, for example, clear on group of cashes >>>> at >>>>>>>>>> once? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" < >>>>>>>>>>>>>> skoz...@gridgain.com> >>>>>>>>>>>>>>>> написал: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I mean not only SQL features for caches. Single type per >>>> cache >>>>>>>>>>>>>>> definitely >>>>>>>>>>>>>>>>> reduces number of caches for regular user and grouping >>>> caches >>>>>>>>>> will >>>>>>>>>>>>>> help >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> manage caches in grid. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin < >>>>>>>>>>>>>>>> sergi.vlady...@gmail.com> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm aware of this issue. My plan was to allow setting the >>>>> same >>>>>>>>>>>>>> schema >>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>> to different caches using CacheConfiguration. >>>>>>> setSqlSchema(...). >>>>>>>>>>>>>> This >>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>> will have separate caches but from SQL point of view >>>>>>> respective >>>>>>>>>>>>>>> tables >>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>> reside in the same schema. No need to introduce new >>>> concepts. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sergi >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov < >>>>>>> skoz...@gridgain.com >>>>>>>>>>> : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> HI >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Due to approach to disable to store more than one type >> per >>>>>>>>>> cache >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> cache >>>>>>>>>>>>>>>>>>> use becomes similar the table use for databases. >>>>>>>>>>>>>>>>>>> So I suppose would be good to introduce a >>>>>>>>>> database/schema-similar >>>>>>>>>>>>>>>>> concept >>>>>>>>>>>>>>>>>>> for caches. It may be implemented as a non-default >>>> behavior >>>>>>> for >>>>>>>>>>>>>>>>> backward >>>>>>>>>>>>>>>>>>> compatibility. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Sat, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan < >>>>>>>>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov < >>>>>>>>>>>>>>>>>>> akuznet...@gridgain.com> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite >>>> 2.0? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Why? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as >>>> of >>>>>>>>>>>>>>>>> **Spark** >>>>>>>>>>>>>>>>>> 2 >>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>> on **scala 2.11**. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do >> we >>>>>>> know >>>>>>>>>>>>>>> what >>>>>>>>>>>>>>>>>> kind >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is still >>>> using >>>>>>>>>>>>>> 2.10? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda < >>>>>>>>>>>>>>>> dma...@gridgain.com> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Let’s add this [1] issue to the list because it >>>> requires >>>>>>>>>>>>>>>>>> significant >>>>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>>>> on the side of metrics SPI. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3495 >>>> < >>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> — >>>>>>>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov < >>>>>>>>>>>>>>>>> yzhda...@apache.org> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Not yet. The thing is that our recent experience >>>> showed >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>> very good idea to go with caches. E.g. when you try >> to >>>>>>>>>>>>>>>>>> deserialize >>>>>>>>>>>>>>>>>>>>> inside >>>>>>>>>>>>>>>>>>>>>>> continuous query listener on client side it >> implicitly >>>>>>>>>>>>>>> calls >>>>>>>>>>>>>>>>>>>>> cache.get() >>>>>>>>>>>>>>>>>>>>>>> which in turn may cause deadlock under some >>>>>>>>>>>>>> circumstances. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> --Yakov >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2016-08-02 2:41 GMT+03:00 Dmitriy Setrakyan < >>>>>>>>>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov < >>>>>>>>>>>>>>>>>>> yzhda...@apache.org> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> One more point. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I insist on stop using marshaller and meta caches >>>> but >>>>>>>>>>>>>>>> switch >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>> spreading >>>>>>>>>>>>>>>>>>>>>>>>> this info via custom discovery events. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Do we have a ticket explaining why this needs to be >>>>>>>>>>>>>> done? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> --Yakov >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan < >>>>>>>>>>>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov < >>>>>>>>>>>>>>>>>>>>> yzhda...@apache.org> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Guys, I think we can also split event >> notification >>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>>>>>> listeners >>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>> internal system listeners. I have been seeing a >>>> lot >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> issues >>>>>>>>>>>>>>>>>>>>> caused >>>>>>>>>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>>>>>>>>>>>> some heavy or blocking operations in user-defined >>>>>>>>>>>>>>>>> listeners. >>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>>>>>>>>>>>> block >>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on >> discovery >>>>>>>>>>>>>>> event) >>>>>>>>>>>>>>>>>>> causing >>>>>>>>>>>>>>>>>>>>>>>>>> topology >>>>>>>>>>>>>>>>>>>>>>>>>>> hangings. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added. >>>> Would >>>>>>>>>>>>>> be >>>>>>>>>>>>>>>> nice >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> assign >>>>>>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all >> the >>>>>>>>>>>>>>>>> discussed >>>>>>>>>>>>>>>>>>>>> features >>>>>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk < >>>>>>>>>>>>>>>>>>>>>>>> alexey.goncha...@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Folks, >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Recently I have seen a couple of emails >>>> suggesting >>>>>>>>>>>>>>>>>>>>>>>> tasks/improvements >>>>>>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>>>>> we cannot do in 1.x releases due to API >>>>>>>>>>>>>> compatibility >>>>>>>>>>>>>>>>>> reasons, >>>>>>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>>>>>> postponed to 2.0. I would like to keep track of >>>>>>>>>>>>>> these >>>>>>>>>>>>>>>>> tasks >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>>> our Jira to make sure we do not have anything >>>>>>>>>>>>>> obsolete >>>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>>>> comes >>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such >>>>>>>>>>>>>> tasks? >>>>>>>>>>>>>>>>>> Should >>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>>>> be a >>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something >>>> else? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov >>>>>>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Sergey Kozlov >>>>>>>>>> GridGain Systems >>>>>>>>>> www.gridgain.com >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Alexey Kuznetsov >>>>>>> GridGain Systems >>>>>>> www.gridgain.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sergey Kozlov >>>>>> GridGain Systems >>>>>> www.gridgain.com >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Sergey Kozlov >>> GridGain Systems >>> www.gridgain.com >> >> > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com
