Great! On Sat, Mar 21, 2015 at 3:08 PM, Selvaratnam Uthaiyashankar < [email protected]> wrote:
> Kernel team is already doing this [2]. I believe others are also doing > that. > > [2] https://github.com/wso2/carbon4-kernel/releases > > On Sat, Mar 21, 2015 at 8:41 AM, Nirmal Fernando <[email protected]> wrote: > >> On a related note, shall we draft the release on GIT itself and host the >> milestone packs in GIT? That's how most of the GIT based code get released >> [1]. >> >> [1] https://github.com/GoogleCloudPlatform/kubernetes/releases >> >> On Wed, Mar 11, 2015 at 5:43 PM, Kasun Indrasiri <[email protected]> wrote: >> >>> Hi Shankar, >>> >>> Yeah, IMO releasing milestones with release plugin would immensely help >>> our continuos delivery objectives. That helps us to minimize the release >>> overhead when we do a GA (if we don't use release plugin, then some of the >>> issues will be only discovered during the GA release time). >>> And, since our objective is to make sure that the milestone releases are >>> stable (and not half-baked), contains a set of features which are don-done >>> and no any major integration test failures, releasing the upstream >>> components is meaningful I guess. WDYT? >>> >>> On Wed, Mar 11, 2015 at 4:45 AM, Srinath Perera <[email protected]> >>> wrote: >>> >>>> In my view, based on what we have discussed so far, we can live with >>>> SNAPSHOT dependancies for milestone releases. >>>> >>>> But we can decide to do more >>>> >>>> 1. If we can align milestone releases with component releases, IMO >>>> it is a good thing to encourage frequent releases of components. >>>> 2. However, it is not good if we need to fork maven release plugin. >>>> 3. One potential solution is to make it optional and ask teams to >>>> release only components they feel are stable in milestone releases and >>>> others can stay as SNAPSHOTs. >>>> >>>> >>>> >>> --Srinath >>>> >>>> >>>> >>>> >>>> On Tue, Mar 10, 2015 at 8:47 PM, Sameera Jayasoma <[email protected]> >>>> wrote: >>>> >>>>> I also believe that for milestone releases we can live with SNAPSHOT >>>>> dependencies as Shankar explained. I don't think we should follow the >>>>> proper release process for milestone releases. >>>>> >>>>> Thanks, >>>>> Sameera. >>>>> >>>>> On Tue, Mar 10, 2015 at 5:36 PM, Selvaratnam Uthaiyashankar < >>>>> [email protected]> wrote: >>>>> >>>>>> Sameera/Kishanthan/KasunG/Srinath, >>>>>> >>>>>> Can you guys comment on this please? >>>>>> >>>>>> On Tue, Mar 10, 2015 at 5:33 PM, Sagara Gunathunga <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 10, 2015 at 5:12 PM, Selvaratnam Uthaiyashankar < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Why do we have to use the release plugin for the milestone >>>>>>>> releases? I don't think it is correct to use the release plugin for >>>>>>>> milestone release. >>>>>>>> >>>>>>> >>>>>>> Maven release plugin was already used by some other teams during >>>>>>> milestone releases and I also under impression that we should use >>>>>>> release >>>>>>> plugin for all releases. If we are not suppose to use release plugin, >>>>>>> shall we agree on following procedure. >>>>>>> >>>>>>> 1. Create a tag in product repo. >>>>>>> 2. Create tags in SNAPSHOT dependency repos. >>>>>>> 3. RM locally build the pack, test and release. >>>>>>> >>>>>>> >>>>>>> Thanks ! >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> We chat yesterday, but I didn't realize we talked about Maven >>>>>>>> release plugin. It shouldn't be forked. >>>>>>>> >>>>>>>> @Kasun, it is similar to ESB depends on carbon-mediation. It is >>>>>>>> developed and maintained by same team. It is valid to depend on >>>>>>>> SNAPSHOT >>>>>>>> for a milestone release. However, you can't depend on SNAPSHOT >>>>>>>> components >>>>>>>> developed by some other team (again, there are exceptions, but team >>>>>>>> has to >>>>>>>> justify that). For example, ESB can't depend on corbon-governance >>>>>>>> SNAPSHOT. >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 10, 2015 at 8:10 AM, Sagara Gunathunga <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 10, 2015 at 12:34 AM, Kasun Indrasiri <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> How about depending only on released components for a given >>>>>>>>>> product milestone? Because a given milestone is a stable pack that >>>>>>>>>> depends >>>>>>>>>> on the stables upstream components. >>>>>>>>>> >>>>>>>>> >>>>>>>>> If I reiterate the problem, ATM carbon-governance/carbon-registry >>>>>>>>> are stable in terms of set of completed features but not yet >>>>>>>>> production >>>>>>>>> ready as whole hence IMHO we should avoid proper release numbers (e.g >>>>>>>>> carbon-registry-4.3.2 ) for something not yet production ready, >>>>>>>>> we should use either post-fix like SNAPSHOT or M2, M3 etc. >>>>>>>>> >>>>>>>>> If we just use proper release numbers for milestone versions it >>>>>>>>> will make disaster for end users (both internal and external) because >>>>>>>>> they >>>>>>>>> can't simply find which version is production ready and which one is >>>>>>>>> not >>>>>>>>> yet ready, usually users tend to use latest available version but >>>>>>>>> with this >>>>>>>>> approach there is a high chance that latest one is not production >>>>>>>>> ready. >>>>>>>>> BTW some of the popular project like Spring[1] use set of post-fix so >>>>>>>>> that >>>>>>>>> end users can easily distinguish GA, Alpha, Beta, M-X versions. >>>>>>>>> >>>>>>>>> [1] - >>>>>>>>> http://repo1.maven.org/maven2/org/springframework/spring-core/ >>>>>>>>> >>>>>>>>> Thanks ! >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 9, 2015 at 2:06 PM, Sagara Gunathunga < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We are about to release G-Reg 5.0.0 M3 pack but found an issue >>>>>>>>>>> when releasing a milestone version. Let me take G-Reg as an >>>>>>>>>>> example, G-Reg >>>>>>>>>>> 5.0.0-M3 version is depends on carbon-governance SNAPSHOT version >>>>>>>>>>> and that >>>>>>>>>>> is a legitimate use as well ( As G-Reg 5.0.0-M3 version, we actually >>>>>>>>>>> release some of the completed features of >>>>>>>>>>> carbon-governance/carbon-registry >>>>>>>>>>> repos.) but Maven release plug-in does not support to release any >>>>>>>>>>> project >>>>>>>>>>> with SNAPSHOT dependencies [1] [4], so we have 2 options to solve >>>>>>>>>>> this >>>>>>>>>>> issue. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *1. ) Modify Maven release plug-in to allow SNAPSHOT >>>>>>>>>>> dependencies.* >>>>>>>>>>> >>>>>>>>>>> Pros >>>>>>>>>>> --------- >>>>>>>>>>> - Fix is relatively straightforward, we just have to remove >>>>>>>>>>> validation in code and allow SNAPSHOT dependencies. >>>>>>>>>>> >>>>>>>>>>> - No change to release process. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cons >>>>>>>>>>> --------- >>>>>>>>>>> - We have to fork and maintain Maven release plug-in locally and >>>>>>>>>>> will lose new changes from Apache. >>>>>>>>>>> >>>>>>>>>>> - If we consider G-Reg-5.0.0-M3 pack, technically it's a >>>>>>>>>>> milestone version not a snapshot version so as a principle 'creation >>>>>>>>>>> process of the pack' should be repeatable but if we allow SNAPSHOT >>>>>>>>>>> dependencies inside product packs 'creation process of the pack' is >>>>>>>>>>> not >>>>>>>>>>> repeatable. This is not something standard, if we decided to go >>>>>>>>>>> with this >>>>>>>>>>> approach at least we should not call them as milestone packs instead >>>>>>>>>>> SNAPSHOT packs (like nightly builds) e.g - >>>>>>>>>>> G-Reg-5.0.0-SNAPSHOT-08-03-15 >>>>>>>>>>> pack etc. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *2.) Instead of SNAPSHOT dependencies, first release own >>>>>>>>>>> dependencies with M-'X' (e.g - carbon-governance-4.4.0-M1 ) and >>>>>>>>>>> then use >>>>>>>>>>> these released versions within the milestone product pack. * >>>>>>>>>>> >>>>>>>>>>> Example - G-Reg 5.0.0-M3 pack can have >>>>>>>>>>> carbon-governance-4.4.0-M2 and carbon-registry-4.3.2-M5 but NOT >>>>>>>>>>> carbon-identity-4.3.1-M2 >>>>>>>>>>> >>>>>>>>>>> Pros >>>>>>>>>>> --------- >>>>>>>>>>> - Again relatively straightforward, we don't need to fork and >>>>>>>>>>> maintain Maven release plug-in. >>>>>>>>>>> >>>>>>>>>>> - AFAIK adding post-fix to distinguish Milestone, Alpha, Beta >>>>>>>>>>> versions is a standard practise [2] , [3] hence end users already >>>>>>>>>>> aware not >>>>>>>>>>> to use milestone versions in production. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cons >>>>>>>>>>> --------- >>>>>>>>>>> - There is a chance that other teams can use M-X packs in there >>>>>>>>>>> milestone releases, we need a proper governance and disciplines >>>>>>>>>>> not to do >>>>>>>>>>> that (e.g - carbon-governance-4.4.0-M1 should be only use by G-Reg >>>>>>>>>>> team >>>>>>>>>>> within WSO2 other than special permissions) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WDYT ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] - >>>>>>>>>>> http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html >>>>>>>>>>> >>>>>>>>>>> [2] - Spring releases - >>>>>>>>>>> http://repo1.maven.org/maven2/org/springframework/spring-core/ >>>>>>>>>>> >>>>>>>>>>> [3] - Hibernate releases - >>>>>>>>>>> http://repo1.maven.org/maven2/org/hibernate/hibernate-search/ >>>>>>>>>>> >>>>>>>>>>> [4] - When I tied for above, build was stopped with following >>>>>>>>>>> error. >>>>>>>>>>> >>>>>>>>>>> [INFO] >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> [ERROR] Failed to execute goal >>>>>>>>>>> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare >>>>>>>>>>> (default-cli) >>>>>>>>>>> on project carbon-governance: Can't release project due to non >>>>>>>>>>> released >>>>>>>>>>> dependencies : >>>>>>>>>>> >>>>>>>>>>> [ERROR] >>>>>>>>>>> org.wso2.carbon.registry:org.wso2.carbon.registry.admin.api:jar:4.3.1-SNAPSHOT:compile >>>>>>>>>>> >>>>>>>>>>> [ERROR] >>>>>>>>>>> org.wso2.carbon.registry:org.wso2.carbon.registry.common:jar:4.3.1-SNAPSHOT:compile >>>>>>>>>>> >>>>>>>>>>> [ERROR] >>>>>>>>>>> org.wso2.carbon.registry:org.wso2.carbon.registry.extensions:jar:4.3.1-SNAPSHOT:compile >>>>>>>>>>> >>>>>>>>>>> [ERROR] >>>>>>>>>>> org.wso2.carbon.registry:org.wso2.carbon.registry.indexing:jar:4.3.1-SNAPSHOT:compile >>>>>>>>>>> >>>>>>>>>>> [ERROR] in project 'WSO2 Carbon - Governance' >>>>>>>>>>> (org.wso2.carbon.governance:org.wso2.carbon.governance.api:bundle:4.3.1-SNAPSHOT) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks ! >>>>>>>>>>> -- >>>>>>>>>>> Sagara Gunathunga >>>>>>>>>>> >>>>>>>>>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>>>>>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>>>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>>>>>>> Blog ; http://ssagara.blogspot.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Kasun Indrasiri >>>>>>>>>> Software Architect >>>>>>>>>> WSO2, Inc.; http://wso2.com >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> cell: +94 77 556 5206 >>>>>>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sagara Gunathunga >>>>>>>>> >>>>>>>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>>>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>>>>> Blog ; http://ssagara.blogspot.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> S.Uthaiyashankar >>>>>>>> VP Engineering >>>>>>>> WSO2 Inc. >>>>>>>> http://wso2.com/ - "lean . enterprise . middleware" >>>>>>>> >>>>>>>> Phone: +94 714897591 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sagara Gunathunga >>>>>>> >>>>>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>>> Blog ; http://ssagara.blogspot.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> S.Uthaiyashankar >>>>>> VP Engineering >>>>>> WSO2 Inc. >>>>>> http://wso2.com/ - "lean . enterprise . middleware" >>>>>> >>>>>> Phone: +94 714897591 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sameera Jayasoma, >>>>> Software Architect, >>>>> >>>>> WSO2, Inc. (http://wso2.com) >>>>> email: [email protected] >>>>> blog: http://blog.sameera.org >>>>> twitter: https://twitter.com/sameerajayasoma >>>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>>> Mobile: 0094776364456 >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>>> >>>> >>>> >>>> -- >>>> ============================ >>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>>> Site: http://people.apache.org/~hemapani/ >>>> Photos: http://www.flickr.com/photos/hemapani/ >>>> Phone: 0772360902 >>>> >>> >>> >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Thanks & regards, >> Nirmal >> >> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >> Mobile: +94715779733 >> Blog: http://nirmalfdo.blogspot.com/ >> >> >> > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > -- Thanks & regards, Nirmal Senior Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
