Hi Suho,
On Fri, Jan 3, 2014 at 5:13 PM, Sriskandarajah Suhothayan <s...@wso2.com>wrote: > I think based on the current Carbon build model, Since your doing API > changes you have to increment the minor version of the component and not > the patch version. > > E.g *4.2.2 to 4.3.0 *and not 4.2.2 to 4.2.3 > I don't think we can create 4.3.x components in turing + go for a new branch is too much overhead. thanks Eranda > > By doing this, even if your product release get delayed simple bug fixes > can be allowed in 4.2.3 for the other products on previous chunk releases. > > Regards > Suho > > > On Fri, Jan 3, 2014 at 3:13 PM, Shelan Perera <she...@wso2.com> wrote: > >> Hi, >> >> +1 for the approach. But it has to be carefully monitored or controlled >> if these components are modified for the first time as mentioned approach. >> Because someone may not follow this procedure without knowing the history. >> >> Thanks >> >> >> On Friday, January 3, 2014, Isuruwan Herath wrote: >> >>> +1 >>> >>> >>> On Fri, Jan 3, 2014 at 11:29 AM, Eranda Sooriyabandara >>> <era...@wso2.com>wrote: >>> >>> Hi Isuruwan, >>> Here with your scenario, there can be a issue if we encounter a bug in >>> registry or governance component where we need to fix in a product release >>> before we release the refactored components. >>> >>> In such a scenario we can follow the following steps >>> 1. Move the refactored code to a next version >>> 2. Copy the released component code to the next version >>> 3. Fix the bug in both refactored and the patch release components >>> >>> E.g : If we need to fix a bug in org.wso2.carbon.governance.api and we >>> fefactored the code in 4.2.2 where the released component version is 4.2.1, >>> then we need to follow the following steps >>> >>> Move the refactored code from 4.2.2 to 4.2.3 >>> Copy 4.2.1 code to 4.2.2 >>> Fix the bug in 4.2.2 and 4.2.3 >>> >>> WDYT? >>> >>> thanks >>> Eranda >>> >>> >>> On Thu, Jan 2, 2014 at 10:42 PM, Isuruwan Herath <isuru...@wso2.com>wrote: >>> >>> Hi, >>> >>> If we are proceeding with new component versions, in the case of common >>> components used by ongoing releases: should a new version be created anyway >>> and proceed and merge later once the release is done? >>> >>> >>> On Thu, Jan 2, 2014 at 9:51 PM, Selvaratnam Uthaiyashankar < >>> shan...@wso2.com> wrote: >>> >>> >>> >>> >>> On Thu, Jan 2, 2014 at 9:51 PM, Selvaratnam Uthaiyashankar < >>> shan...@wso2.com> wrote: >>> >>> >>> >>> >>> On Thu, Jan 2, 2014 at 9:32 PM, Senaka Fernando <sen...@wso2.com> wrote: >>> >>> Hi Shankar, >>> >>> Yes that's what we do right now. But, wouldn't this complicate parallel >>> development work, especially if two or more products start changing common >>> components in separate scratch areas? (ex:- we had a bad experience >>> sometime back when the IS changes done in scratch were merged into release >>> branch). >>> >>> IMHO, may be we don't need to have a chunk08 (that's just a grouping for >>> the build), but we do need to use the same branch to commit changes. Of >>> course with new version numbers if the components have been releases >>> already. >>> >>> Based on what we (Azeez/Sameera/SameeraP/myself) discussed in the >>> morning (correct me if I'm wrong), unless we keep committing to the branch, >>> we loose patches etc that were provided for a previous release. >>> >>> >>> >>> Yes, in that case, you can create a new component version and commit >>> there, but not create the chunk08 folders. How are we going to build those >>> components is an issue. one option is to create "chuck-future" >>> >>> >>> *chunk-future >>> >>> >>> or some folder and have the build configured there and move the >>> components from there to correct chunk when we decide the chunk. WDYT? >>> >>> Regards, >>> Shankar >>> >>> >>> >>> >>> Thanks, >>> Senaka. >>> >>> >>> On Thu, Jan 2, 2014 at 9:22 PM, Selvaratnam Uthaiyashankar < >>> >>> >> >> -- >> Sent from Gmail Mobile >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > > *S. Suhothayan* > Associate Technical Lead, > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Eranda Sooriyabandara*Senior Software Engineer; Integration Technologies Team; WSO2 Inc.; http://wso2.com Lean . Enterprise . Middleware E-mail: eranda AT wso2.com Mobile: +94 716 472 816 Linked-In: http://www.linkedin.com/in/erandasooriyabandara Blog: http://emsooriyabandara.blogspot.com/
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
