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
