Changes between Version 51 and Version 52 of BuildSystem


Ignore:
Timestamp:
12/15/12 14:16:51 (7 years ago)
Author:
welberge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BuildSystem

    v51 v52  
    9090 
    9191* Basically, we use version numbers of the form major.minor where major are minor are numbers. Examples: 0.1, 1.4, 2.0, 2.0.1. 
    92 * We allow sufixes of the form -alpha, to denote alpha release versions, and -devi, where i some number, to denote "daily releases" (or developer versions). So, for instance, 2.0-dev384 is a developer version, working towards full release 2.0. 
     92* We allow sufixes of the form -alpha, to denote alpha release versions, and -devi, where i some number, to denote "daily releases" (or developer versions). So, for instance, 2.0-dev384 is a developer version, working towards full release 2.0. 
    9393* The major.minor form is the preferred form for full releases. 
    94 * The major.minor-alpha form is the preferred form for alpha releases. 
    95 * The major.minor-devi form is used as a "developer version" for release major.minor. Such versions are produced during our "nightly" build 
    96 process. (Should be running on a daily basis; but when testing during the nightly build produces error, no new versions are published that night). Daily builds are thus more stable than alphas, in that they are guaranteed to pass the test cases. The number i matches to the build number on the daily build server. Therefore, daily builds should only be produced by the build server; if an inbetween daily build is desired, one can create on by starting the daily build job on the build server. TODO: currently only Herwin can do this... 
    97 * Version numbers for full releases and dev releases are to be unique. Once published, you cannot reuse the same version number for a new 
    98 release anymore. For alpha versions this would be counterproductive, since alpha versions can be produced in rapid succession, with only very 
    99 minor differences. For this reason, our strategy is that alpha releases will not be put on the repository, so are not shared, therefore do not need 
    100 unique version numbers. Sometimes we use version numbers of the form major.minor.maintenance. This form is intended for releases that are bug fixes for normal major.minor releases. Say currently we have a release version 2.3, and we already produced newer beta versions 2.4 and 2.5. Then we detect an annoying bug in 2.3. Now we could correct this and then produce a full release 2.6, but that would also include our new/experimental/buggy beta and alpha 
    101 code from 2.4, 2.5. The better solution here would be to use git to temporarily revert to the code of version 2.3, do the bug fixing, then 
    102 publish that as maintenance release version 2.3.1. Note that this is a release version, not an alpha or beta, so it that will become the preferred 
    103 one when resolving for a "latest release" version. 
     94* The major.minor-alpha form is the preferred form for alpha releases. 
     95* The major.minor-devi form is used as a "developer version" for release major.minor. Such versions are produced during our "nightly" build process. (Should be running on a daily basis; but when testing during the nightly build produces error, no new versions are published that night). Daily builds are thus more stable than alphas, in that they are guaranteed to pass the test cases. The number i matches to the build number on the daily build server. Therefore, daily builds should only be produced by the build server; if an inbetween daily build is desired, one can create on by starting the daily build job on the build server. TODO: currently only Herwin can do this... 
     96* Version numbers for full releases and dev releases are to be unique. Once published, you cannot reuse the same version number for a new release anymore. For alpha versions this would be counterproductive, since alpha versions can be produced in rapid succession, with only very minor differences. For this reason, our strategy is that alpha releases will not be put on the repository, so are not shared, therefore do not need unique version numbers. Sometimes we use version numbers of the form major.minor.maintenance. This form is intended for releases that are bug fixes for normal major.minor releases. Say currently we have a release version 2.3, and we already produced newer beta versions 2.4 and 2.5. Then we detect an annoying bug in 2.3. Now we could correct this and then produce a full release 2.6, but that would also include our new/experimental/buggy beta and alpha code from 2.4, 2.5. The better solution here would be to use git to temporarily revert to the code of version 2.3, do the bug fixing, then publish that as maintenance release version 2.3.1. Note that this is a release version, not an alpha or beta, so it that will become the preferred one when resolving for a "latest release" version. 
    10497 
    10598== Starting point ==