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
