Changes between Version 50 and Version 51 of BuildSystem

12/15/12 14:16:05 (7 years ago)



  • BuildSystem

    v50 v51  
    8282with the most recent release version. 
     84== Version numbering == 
     85We use some conventions; the Ivy system does not require some particular 
     86numbering scheme, but uses version numbers to determine which version is 
     87"more recent". This includes a few subtle cases. For instance, Ivy knows that 
     88version 1.4-alpha is before 1.4, and that versions 2.0-rc1 and 2.0-dev384 
     89are both before 2.0. Our conventions: 
     91* 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. 
     93* 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 
     96process. (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 
     98release anymore. For alpha versions this would be counterproductive, since alpha versions can be produced in rapid succession, with only very 
     99minor 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 
     100unique 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 
     101code 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 
     102publish 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 
     103one when resolving for a "latest release" version. 
    85105== Starting point ==