Release.hpp File Reference

Plans regarding releasing the software. More...

Go to the source code of this file.

Detailed Description

Plans regarding releasing the software.

The special aspect of package building is treated in Buildsystem/ReleaseProcess/plans/PackageBuilding.hpp

  • Different types of developers:
    1. main developer (OK)
    2. core developer (full access to main repository)
    3. local developer (only access to a controlled clone; local to Swansea)
    4. external developer (only access to a controlled clone)
  • See "Developers information" in Buildsystem/Configuration/plans/Persons.hpp.
  • Different defaults for mailing lists.
  • Everybody can submit patches.
  • Perhaps everybody except core developers should (always) work with branches ?! Submission then to the master-branch.
  • Local and external developers each have their own dedicated push+pull clones. Core developers connects it with the main repository.
Release plan
  • In Annotations/Release-1_0 we have a release plan for version 1.0 --- what to do with this plan?
    1. Move all plans there to the appropriate plans in OKlib.
    2. Part I on components delived should be integrated into the respective milestones.
    3. Some with Part VII.
    4. "Supported platforms": We must do something about Linux/Unix, while the rest is not supported.
    5. The relative order in the schedule can be considered when integrating the plans.
    6. Part IV on "Usage" should go to here.
    7. Compare V, VI with "MailingLists.hpp".
  • DONE (all plans more here) Release plans perhaps should move to here --- or stay in Annotations?
ExternalSources repository
  • In cs-oksvr:/work/Repositories/ExternalSources_recommended we store the (currently) recommended versions. We need then (likely under Configuration) a "database" with md5sum-results. See Buildsystem/plans/Configuration.hpp.
Special tag
  • A special Git-tag for a release should be created?
  • Or is it identical with a new version of the library? Looks better.
  • The special tag should be a "full tag", with signature etc.
  • But perhaps we postpone the signature for now.
  • Name of the tag
    (compare package-names in Buildsystem/plans/PackageBuilding.hpp).
  • Message just for example 'New version ("THEME")'.
  • Compare with "Tagging" in Buildsystem/SourceControl/plans/general.hpp.
Improved releases
  • What kind of clones does the user get?
    1. One master-user-clone is created on cs-oksvr, and the users get clones of it as described in "Copied clones which know how to connect" in Buildsystem/plans/VersionControl.hpp.
  • How user can update:
    1. The simplest category of user only uses the releases (the packages; see "Package construction script" below).
    2. An "active user" has pull-access to the dedicated user-clone.
    3. Finally a user can become a "developer" (see "Developers" below).
    Perhaps the dedicated user-clone is only updated "every few days".
  • How can we create special "views" for the users? They should be able to register for modules or subjects, and then get commit-notifications related to those modules. Sending them also the patches? Or the new files??

Definition in file Release.hpp.