# Version strings in HWS # # The main "Ruby" string is a legal version of our "Product Release # Identification Standard": # # https://confluence.perforce.com:8443/display/EN/Product+Release+Identification+Standards # # A few notes: # # 1. While HWS does build for different OSes, it does not have an explicit # architecture. So we use "NOARCH". # # 2. The "Product ID" is currently "HWS". # # 3. We do include the date and changelist of the *tarball*. # # An official verison may be: HWS/NOARCH/2015.1/123456 (2015/08/17) # # A pre-release version will include information in the middle: # # HWS/NOARCH/2015.1.MAIN-TEST_ONLY/123456 (2015/08/17) # # For Ruby, the version string will be [YEAR].[REV].[CHANGELIST]. # Preleases will have a branch specifier: [YEAR].[REV].0.[branch][CHANGELIST]. # # Ergo, a Ruby version string will look like 2015.1.0.main123456 # # These strings are either defined in a file `./build_version.rb`. module HelixWebServices VERSION = '2015.1.0.main' end file_path = File.absolute_path('../build_version.rb', __FILE__) if File.exists?(file_path) require_relative './build_version' else module HelixWebServices PRODUCT_ID = 'HWS/NOARCH/2015.1.MAIN/1' end end
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 15741 | ptomiak | Branch HWS for my use. | ||
//guest/perforce_software/helix-web-services/main/source/helix_web_services/lib/helix_web_services/version.rb | |||||
#2 | 15660 | tjuricek | Altering how the build_version.rb gets generated, and not requiring it at the moment. | ||
#1 | 15622 | tjuricek |
Move source code to 'source/' subdirectory of branch. build/ will remain where it is. |
||
//guest/perforce_software/helix-web-services/main/helix_web_services/lib/helix_web_services/version.rb | |||||
#2 | 15513 | tjuricek |
Add a product ID header for debugging purposes. This will generally display INVALID unless the version file has been created during the build. |
||
#1 | 13799 | tjuricek |
Start with branch specs hosting in a new monolithic 'helix web services' project. Converting from a microservice to a monolithic architecture due to resource constraints at getting a deployable system running. Additionally, since it's not expected that people will upgrade often, the major benefit of microservices - being able to add services individually without affecting others - is not really a major benefit. The Ruby SDK will be consolidated into a single 'helix web services client' project. It may end up being distributed via Rubygems. This only runs branch specs at the moment. I want to get a CD pipeline setup for the monolithic server before revising more methods. |