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