Development Cycle

LeoColomb edited this page Jun 3, 2013 · 2 revisions

YOURLS development & release cycle – "Mostly Semantic Versioning"

This document tries to explain the development and release cycle goals for YOURLS.

It describes goals more than laws : YOURLS is and should remain a fun "week-end project" and as such we don't want to obey rigid rules detrimental to flexibility or general freedom. But just because we are a bunch of Internet hippies does not mean we should not try to follow a few simple key principles.

Short version: this resembles Semantic Versioning, with more MIGHT and less MUST, and were SHOULD means "will PROBABLY happen", not "WILL happen".

Stable version release

  1. Release stable version

    When the current build is considered satisfying enough, it will be tagged (YOURLS version X.Y) and, as such, will be listed in the tags page.

    This version will be considered the latest stable official build available and its code won't change.

  2. Deprecate previous versions

    All previously released stable versions will be considered obsolete, deprecated and unsupported.

    All users are advised to always update to the latest stable version available.

Development of next iteration

  1. Bump version

    In the master branch, the version number will be incremented to A.B-[scary-label], such as 1.7-alpha.

  2. Hack, fix, improve

    Add new features, fix reported bugs, improve existing code.

    The [scary-label] might evolve to reflect code stability and/or developers mood: alpha, do-not-use, omg-panic, looks-awesome... Developers will do their best not to be too creative here :)

    As a rule of thumb, the master branch should always be rather stable enough, even during early phases. http://yourls.org/ typically runs the latest master.

    Less stable or quickly evolving features may be introduced in topical branches before being merged into master.

  3. Special case: Patch version

    If, during development of next iteration, a serious bug or flaw in previous latest stable build is discovered and fixed, a patch version (X.Y.Z) will be issued. It may or may not contain some of the new features developed for the next iteration, depending on their complexity and readiness.

  4. Release Candidate

    When new features are polished enough, the version will be bumped to A.B-RC1 (eg 1.7-RC1). This unofficial milestone should lead to feature freeze and string freeze.

    • Feature freeze

    At this point, new features should not be introduced.

    At this point, the YOURLS team should send a call to plugin authors: this milestone is an important opportunity to verify plugin compatibility and make sure no change introduced in YOURLS inadvertently breaks a previously functional plugin.

    Depending on plugin authors feedback, this phase could lead to several bug fixes and will last as long as necessary to make sure backward compatibility is assured, unless explicitly stated otherwise — see versioning below.

    • String freeze

    At this point, new translatable strings should not be introduced, and existing strings should not be modified.

    At this point, the YOURLS team should send a call to translators: this milestone is a opportunity to rapidly review the few translation string changes since last stable version and release an update translation file as close as possible to the official release of the next YOURLS stable version.

    This phase should not last longer than one or two weeks: it's the responsibility of translators to provide, if and when they wish to do so, an updated translation file.

  5. Library update

    During previous phases, developers should update third party libraries and dependencies, such as jQuery, ezSQL, GeoIP database...

    YOURLS development pace being rather slow, the goal should be to always release a stable build with latest up-to-date libraries, and maybe postpone the release of the next stable version of YOURLS a bit if the release of an updated library is imminent.

Versioning

For transparency and for striving to maintain backward compatibility, YOURLS versioning takes inspiration from the Semantic Versioning guidelines.

Releases will be numbered with the following format: <major>.<minor>[.<patch>] and constructed with the following principles:

  • Breaking backward compatibility bumps the major (and resets the minor and patch)

  • New additions without breaking backward compatibility bumps the minor (and resets the patch)

  • Bug fixes and misc changes bumps the patch number

When backward compatibility is explicitly broken (eg YOURLS 2.0), coders and plugin authors may seek assistance from YOURLS developers for advices to make their code evolve as expected. Most likely, updating guides for coders and plugin authors should be published on the YOURLS blog.

Related

Related documents :