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