Hi Prabath, Regarding the option 2 given and your feedback on it,
IMO, the solution given by you doesn't fit us because of following reasons, - We got to know that there are lot of fixes included in kernel-4.4.1 over 4.4.0. Hazelcast upgrade, Registry life cycles are not working on mounted environment and the list of L1 fixes done [1] are the best examples. So knowingly kernel-4.4.0 is buggy with these issues and fixes are already available with kernel-4.4.1, we do not want to do AppM new release with kernel-4.4.0. [1] https://wso2.org/jira/browse/CARBON-15146?filter=12323 - And we suggest to create a new branch and maintain by your team because AppM product doesn't have a requirement of releasing 4.4.0 based repo for AppM product release. MDM having the requirement. Several teams have done this as their requirements even though it's not the best option and cause trouble for product team (here AppM) in support etc. eg : 1. ES team had created separate branch for AppM 1.0.0 release and we send pull requests for ES team. https://github.com/wso2/product-es/tree/app-manager 2. IS team had created a separate branch for APIM/ AppM releases based on kernel-4.2.0 since their release is based on kernel 4.4.x. https://github.com/wso2/carbon-identity/tree/release-4.2.5 3. APIM team had created new synapse version for their release and took the responsibility of it. There should be many other scenarios like this as per the situation. Anyway, I think the problem is sorted now, since kernel-4.4.1 upgrade works for you. Regards, Dinusha. On Mon, Aug 10, 2015 at 10:27 AM, Prabath Abeysekera <[email protected]> wrote: > Hi Chanaka, > > On Monday, August 10, 2015, Chanaka Fernando <[email protected]> wrote: > >> Hi Prabath, >> >> We have upgraded from kernel 4.4.0 to 4.4.1 with the ESB 4.9.0 Beta >> release. We were using 4.4.0 up until Alpha release and we have upgraded >> carbon-mediation, wso2-axis2-transports and product-esb to use kernel 4.4.1 >> with Beta release. We haven't encountered any issue after upgrading into >> 4.4.1. Your arguments might be correct. But I think you can give it a try >> to upgrade your components to kernel 4.4.1. I am suggesting this to you >> from the experience we gained from ESB beta release. >> > > Thanks for the feedback. Sure, let me give it a try and see. > > Cheers, > Prabath > > >> >> >> Thanks, >> Chanaka >> >> >> >> On Mon, Aug 10, 2015 at 8:50 AM, Prabath Abeysekera <[email protected]> >> wrote: >> >>> Hi Dinusha, >>> >>> Thanks for taking time to help us with this. Please find my comments >>> inline. >>> >>> On Sun, Aug 9, 2015 at 11:38 PM, Dinusha Senanayaka <[email protected]> >>> wrote: >>> >>>> Hi MDM Team, >>>> >>>> Initial plan was to release AppM-1.1.0 release based on carbon-4.4.0. >>>> But due to some issues in the synapse version released with carbon-4.4.0, >>>> we need to move to Synapse 2.1.3.wso2v6 which will be released with >>>> ESB 4.9.0. For that the the carbon.meadiation.feature should be 4.4.3 >>>> which eventually depends on carbon 4.4.1. And there are some registry >>>> related issues that fixed in carbon-4.4.1. Because of these reasons we have >>>> to move AppM release to carbon-4.4.1. >>>> >>>> Since you guys need AppM mobile features to be included into MDM, you >>>> have two options here, >>>> 1. Move MDM release also into carbon-4.4.1 >>>> >>> >>> The team can surely consider going for this option, but, only as the >>> last resort. We'd already released a number of milestones upon Carbon >>> 4.4.0, so if we're forced to upgrade everything to use Carbon 4.4.1 (In >>> other words, adapting a "new" kernel release) just to fix a bug in one of >>> the dependent components, approaching EMM 2.0.0 Alpha in less than a month, >>> then there's a problem in the system that needs to be fixed. I do >>> understand the fact that the release number (i.e. 4.4.1) suggests that it >>> is a patch release, so, unlikely that there'd by any API changes, etc >>> around. Therefore, one might think it is a straight forward task to upgrade >>> all "device-mgt" components to use the latest version of Carbon kernel. >>> However, unfortunately, it's not only about device-mgt related components, >>> but quite a few other stuff as well. In other words, there should be quite >>> a few other components that depend on 4.4.0, which would need to be >>> upgraded as well. I wouldn't take that risk to upgrade them all at this >>> stage of the release, just to get an issue fixed in one of the components. >>> >>> >>>> 2. Since MDM doesn't require AppM gateway features, we could create a >>>> separate branch for you only with store/publisher/mobile features based on >>>> carbon-4.4.0 and you have to maintain the branch. (AppM master is still >>>> based on carbon-4.4.0, we could create this branch before we upgrade it to >>>> carbon-4.4.1) >>>> >>> >>> AFAIK, the process demands us to release all components maintained in a >>> particular repository at once. So, I don't quite think releasing individual >>> components is possible. On the other hand, this just appears to be a "patch >>> solution", which doesn't seem scale well going forward. >>> >>> Also, I'm a little concerned by the statement, "*based on carbon-4.4.0 >>> and you have to maintain the branch*". Why would some other team >>> "maintain" app-mgt source branches? If this is about fixing bugs, etc that >>> the EMM team comes across while adapting app-mgt related components, we >>> ourselves would anyway go for it as time permits. However, creating some >>> branch and asking other teams to "maintain" the same is against collaborate >>> development, IMO. If you create a new version of the components, that will >>> at some point be used by the "whole platform". So, asking some other team >>> to "maintain" the components owned by your team, as you can obviously see, >>> does not seem to scale. >>> >>> With all the above considered, I'm suggesting the following, which I >>> think is the best option. >>> >>> * Update "carbon.mediation.feature" to use "2.1.3.wso2v6" and make its >>> version something like "4.5.*" (ESB team can probably decide on a proper >>> version number if what's suggested doesn't appear to be good). The idea is, >>> even though 4.4.1 appears to be a patch release of Carbon 4.4.0, it has to >>> be a big deal for a component to adapt to a new kernel version. Also, IMO, >>> each and every component should let us have enough room to fix bugs of an >>> already released version that depends on the Kernel version it was >>> originally released upon. >>> >>> * Next, create a new version of "carbon.mediation.feature", which >>> depends on Carbon 4.4.0 and upgrade its synapse version to be " >>> 2.1.3.wso2v6". This is what needs to be used by the app-mgt components. >>> >>> * Get the app-mgt repo released so that the EMM can then adapt all >>> required components on top of Carbon Kernel 4.4.0. >>> >>> >>> Please do let me know if you think it's going to be challenging to get >>> the above to work, or if you need further clarifications. >>> >>> Cheers, >>> Prabath >>> >>> >>>> >>>> Let us know the preferred option for MDM release. >>>> >>>> Regards, >>>> Dinusha. >>>> >>>> -- >>>> Dinusha Dilrukshi >>>> Associate Technical Lead >>>> WSO2 Inc.: http://wso2.com/ >>>> Mobile: +94725255071 >>>> Blog: http://dinushasblog.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> Prabath Abeysekara >>> Technical Lead >>> WSO2 Inc. >>> Email: [email protected] >>> Mobile: +94774171471 >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> -- >> Chanaka Fernando >> Senior Technical Lead >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 773337238 >> Blog : http://soatutorials.blogspot.com >> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >> Twitter:https://twitter.com/chanakaudaya >> Wordpress:http://chanakaudaya.wordpress.com >> >> >> >> -- Dinusha Dilrukshi Associate Technical Lead WSO2 Inc.: http://wso2.com/ Mobile: +94725255071 Blog: http://dinushasblog.blogspot.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
