Skip to content

Project processes

Jump to bottom Edit New page
Alex Povar edited this page May 2, 2018 · 18 revisions

About

This guide documents some internal project processes, so they are shared across all the AutoFixture project members.

Version update

Currently the repository state is used to calculate the current product version. Later during the build this version is applied to all the projects (e.g. AssemblyInfo files are patched), so the produced artifacts are of the resolved version. This means that manual version update is not required.

The version calculation logic is based on last tag and number of commits since last tag. If number of commits is zero (meaning that current commit is tagged), only tag information is used. Only SemVer tags participate in version calculation. A SemVer tag has the following format: v[Major][Minor][Revision][Optional pre-release suffix] (e.g. v3.50.2, v4.0.0-beta1, v4.0.0-rc2). All other tags are ignored by the version calculation logic.

Warning! In order to not break the version resolution logic, it's recommended to not create non-SemVer tags which might be mistakenly matched as SemVer ones. Therefore, avoid creation of tags starting with v character. If it appeared that non-SemVer tag is required, validate that version calculation logic is still not broken.

When you create a pre-release tag, always end it with a number (valid: v4.0.0-beta1, invalid: v4.0.0-beta).

Release process

Deployment of new versions was automated and happens automatically as soon as a new tag was pushed. It's possible to create a tag using the GitHub UI, therefore the following steps are suggested:

  1. Review all the changes since the last SemVer tag and evaluate the next version in accordance with SemVer 2.0.0.

  2. Draft a new release using GitHub UI:

    1. fill the "Tag version" field with a new SemVer tag describing a new version. Example: v3.53.1;
    2. pick up the branch or commit that should be tagged. Usually, that is the master branch;
    3. fill the title with Version VERSION, where VERSION is a new version without the v prefix (example: Version 3.53.1);
    4. describe changes in the body;
    5. set the "pre-release" mark if new tag contains a pre-release suffix (e.g. -beta1).

  3. Press the "Publish Release" button.

  4. Wait for the CI build to finish. Ensure that build finished successfully, so everything was pushed.

  5. Verify that new packages were pushed to NuGet.

  6. Make a tweet about new release on our Twitter account.

Internally, when you push a SemVer tag, the sequence is following:

  • Tag is pushed.
  • AppVeyor starts a new build with a tag trigger.
  • Version calculation logic pick up that tag and use it to calculate the current version.
  • The PublishNuGetPublic FAKE target is activated and it pushes all the necessary artifacts to the public NuGet feed.

Pull Request review

Pull Requests are reviewed by the @AutoFixture/core team members.

Pull Request may be merged only if:

  • It is approved. To consider PR approved it should either:
    • has at least 2 approvals from the core team members;
    • has a single approval from any core team member and at least a week of lifetime.
  • It doesn't have pending reviews.

This approach should allow all core team members to be aware of a PR and put their opinions before it's merged. On other hand, if most of the maintainers are busy, project will be alive if at least a single maintainer is active.

Thank you.

Add a custom sidebar
Clone this wiki locally