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 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 <[email protected]> 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 >> <[email protected]>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 <[email protected]>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 < >> [email protected]> wrote: >> >> >> >> >> On Thu, Jan 2, 2014 at 9:51 PM, Selvaratnam Uthaiyashankar < >> [email protected]> wrote: >> >> >> >> >> On Thu, Jan 2, 2014 at 9:32 PM, Senaka Fernando <[email protected]> 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 > [email protected] > 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 | 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 [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
