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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
