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&type=&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
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
