OpenDUNE:Releases

From OpenDUNE

Jump to: navigation, search

To maintain a lively release cycle, the following guidelines have been put in.

Contents

Version strings

Every official release of OpenDUNE shall be versioned according to the following guidelines: OpenDUNE major.minor[.build[.revision]][suffix]

The following restrictions should apply:

  • Official releases use only the major.minor numbers, with an optional .build , .revision is NOT used, to indicate official releases.
  • Unofficial releases should, at all times, use the full major.minor.build.revision version, to both indicate a non-official build, and the public VCS revision it was based off of.
  • Official releases will use the suffix RC-# to indicate Release Candidates (if applies), Unofficial builds are allowed (and encouraged) to use their own suffix as well as the RC suffix to allow users to identify their work.
  • A Suffix should be kept short and unique to it's purpose, also, if a RC suffix is used, it should be the very last suffix of a version string.
  • Branches should be identified by their own (unique) suffix.


Examples

  • Official builds
    • OpenDune 0.1
    • OpenDune 0.2.1
    • OpenDune 1.0 RC-1
    • OpenDune 1.9.5 RC-5
  • Unofficial builds
    • OpenDune 0.1.0.179
    • OpenDune 0.2.1.869 MOO
    • OpenDune 1.0.0.13614 RC-1
    • OpenDune 1.9.5.324563 MOO RC-5

Release Cycle

Official releases are (unless otherwise notified) released at least every 3 months, the version number will be changed according to the changes made.

The Release Schedule contains information regarding upcoming releases and those already released

Pre-Release Cycle

2 weeks prior to a new release, all new requests(or patches) aimed at new features will be put on hold, and development will be mainly focused on ironing out any known issue that can be fixed in the timespan This cycle has no direct effect on branches, however, in the case of an intended branch merge with trunk, this should also be done prior to the pre-release cycle.

The Release Schedule can be found here

Patches

While we encourage others to submit patches to improve or add features, or fix bugs, it is up to the Developers (and, by hierarchy, the Lead Developers) to decide whether the patch follows the concept of this project. A few rules apply to submitting patches, and/or getting them approved for trunk

  • Every patch has to be approved by a Developer, in doubt, a second developer, or a Lead developer will be requested to assist in this preliminary approval
  • Every patch should adhere to the Coding Standards as used by this project, if this is not done, the patch will be refused inmediately
  • The Development team reserves the right to refuse any patch for any reason, regardless of community support (or lack thereof)
  • Information regarding refusal will be discussed with the creator, not with <random fan of patch>... If you haven't made a patch and you want to know why it is refused, ask the person who made it. (Exceptions can be made)
  • Patches should be stable and tested, prior to submitting them, while this cannot be controlled it doesn't take a rocket scientist to understand that 10-20 minutes of testing your own patch can save a developer a few hours time in fixing them afterwards.
Retrieved from "http://wiki.opendune.org/OpenDUNE:Releases"
Personal tools