Hi Susinda On Wed, Feb 8, 2017 at 12:00 PM, Susinda Perera <[email protected]> wrote:
> + Naming convention for build jobs > devstudio-tooling-esb, devstudio-tooling-platform and so on, i.e same as > the repo name. > +1 for uniformity of devstudio-* job names. This will help to signify the repo name which the job is building. > > > > > On Tue, Feb 7, 2017 at 11:44 PM, Susinda Perera <[email protected]> wrote: > >> Hi All >> I'm thinking of subject as I found some difficulties when trying to >> release a product tooling. Note that we have following repos[1]. >> Currently we have to set following parameters to trigger a build >> 1. Release_Type - Product Release or Update Release >> 2. kernel_version - eg 4.1.0, 4.2.0 or etc >> 3. Product_code - eg platform, esb, dss, apim, ei and so on >> 4. Features_List - All >> 5. Name of the release branch - eg master >> 6. Releasing_version - Name of your release eg RC2 , Beta >> 7. Tag - Create a tag - true/false >> 8. Publish_into_staging_p2 - Publish p2 into staging p2 repository - >> true/false >> 9. Publish_main_p2 - Create composite p2 repository - true/false >> 10. Publish_composite_p2 - Create composite p2 repository (Product plugin >> + Platform Plugin + Kernel plugins) - true/false >> 11. Publish_Installed_Distribuntions - Create Installed distributions >> (composite + eclipse) - true/false >> >> I'm suggesting to use only the params 5,10,11,7 and 8 on same order. Let >> me explain why we do not want other params >> 1 - For update releases, we see that(from the updates released so far) we >> have released the entire repo (have no other option as well), not a >> particular feature only. And also eclipse p2 installer takes care of >> installing only the updated components, so it does not matter if we release >> the entire repo even we have a fix in only one component. So we can go >> with Release_Type=='Product Release' in all the times. Also 4. Feature_List >> param is broken, is seems it only works for one feature, cannot use 'All' >> or comma separated names of features. Therefore we can omit the parameter 1 >> and 4. >> 2 - Kernel version is already defined in the pom and MANIFEST.MF when >> declaring dependencies >> 3 - For a particular repo eg devstudio-tooling-ei we don't want to >> specify the product code again as 'ei' as its redundant >> 4 - Discussed in 1. above - We do not want this if we go for >> Release_Type=='Product Release' always >> 6 - Releasing version - This can be derived from pom >> 9 - Simplest build is the building main-p2, so we can have this as the >> default for all builds, Additional builds may contain composite p2 or >> installed disttributions >> >> Once the build is success with param 9, or (9 and 10) or (9 and 10 and >> 11) then we can create a tag and publish into staging p2. Hence 7. and 8. >> params are placed at the end. >> >> Also id like to suggest following rules for build. >> Continuous build has to be configured with master branch - It may or may >> not use 10 and 11 -TBD >> For releases - A branch has to be created and branch name should be in >> following format - <version>-release - eg 4.1.1-release >> Once released, build job should create a tag in github with his format >> <version>-release-$GIT_TAG_SAFE_BUILD_TIMESTAMP eg - >> 4.1.1-release-2017-02-07-233842 >> For updates - A branch need to be created and should be of following >> format - <version>-update-N - eg 4.1.1-update-1, 4.1.1-update-2, >> 4.1.1-update-3 etc >> Once update build is success build job should create a tag in following >> format - <version>-update-N-$GIT_TAG_SAFE_BUILD_TIMESTAMP, eg >> 4.1.1-update-3-2017-02-07-233842 >> >> *Summary* >> we may use following params >> 1. Name of release branch - eg 4.1.1-release >> 2. Publish_composite_p2 >> 3. Publish_Installed_Distribuntions >> 4. Tag >> 5. Publish_into_staging_p2 >> Branch names for releases and updates has to use following naming pattern >> 4.1.1-release or 4.1.1-update-3 >> Tag names should have similar pattern with $GIT_TAG_SAFE_BUILD_TIMESTAMP >> appended by the build job >> >> Note that this is just few ideas came to my mind for $subject. I might >> have missed some use cases or this might not work, Therefore please share >> your thoughts and good if we can have a discussion on this. >> >> [1] - Repo List >> https://github.com/wso2?utf8=%E2%9C%93&q=devstudio-tooling&t >> ype=&language= >> >> Thanks >> Susinda >> >> >> -- >> *Susinda Perera* >> Software Engineer >> B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) >> Mobile:(+94)716049075 >> Blog: susinda.blogspot.com >> WSO2 Inc. http://wso2.com/ >> Tel : 94 11 214 5345 Fax :94 11 2145300 >> >> > > > -- > *Susinda Perera* > Software Engineer > B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) > Mobile:(+94)716049075 > Blog: susinda.blogspot.com > WSO2 Inc. http://wso2.com/ > Tel : 94 11 214 5345 Fax :94 11 2145300 > > -- Thanks & Best Regards, Maheshika Goonetilleke Senior Engineering Process Coordinator *WSO2 Inc* *email : [email protected] <[email protected]>* *mobile : +94 773 596707* *www: :http://wso2.com <http://wso2.com/>*lean . enterprise . middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
