New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versioning + Release System #220

Closed
marbemac opened this Issue May 24, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@marbemac
Copy link
Member

marbemac commented May 24, 2018

@casserni @lottamus gathering my thoughts here. Can break this up into separate platform issues when ready to finalize.

Intent is to take the generic branch related features @casserni already built, and put a more formalized version + release structure to it.

Whatever pattern we decide on, it should:

  • be simple to understand and use for users that don't know git
  • should guide users towards a sane default versioning/release process, while not being too inflexible
  • should not require merges at any point

New API Services

  • versions service
    • are git branches
    • represented by version/{major}.{minor} branch (always major.minor)
    • are mutable (editing enabled)
    • are branched off of their latest anscestor version upon creation. examples:
      • given existing versions 1.0, 1.1, a new 1.2 version would branch off of the 1.1 version
      • given existing versions 1.0, 1.1, a new 1.5 version would branch off of the 1.1 version
      • given existing versions 1.0, 1.1, a new 2.0 version would branch off of the 1.1 version
      • given existing versions 1.0, 1.5, a new 1.4 version would branch off of the 1.0 version
      • given existing versions 1.0, 1.5, a new 2.0 version would branch off of the 1.5 version
      • given existing versions 1.0, 2.0, a new 3.0 version would branch off of the 2.0 version
      • given existing versions 1.0, a new 3.0 version would branch off of the 1.0 version
      • given no versions, a new 2.0 version would branch off of the master branch
    • when a new version is created, if it is the new latest version then make it the default in the project
  • releases service
    • are git tags
    • represented by {major}.{minor}.{patch} tag (always all three)
    • are immutable (editing disabled)
    • on creation, are created from the related version branch (and thus will point to the latest commit on that branch). for example: release 1.0.0 would create from version/1.0 and release 2.3.4 would create from version/2.3
    • if the version branch does not exist, create it before creating tag (version creation should still follow creation rules described in the versions section above)
    • bonus: on create release, if this is a new latest release, merge related version branch into master. thus, master would always represent the latest release state.

New Project State

  • every project starts on version 1.0 (version/1.0 branch under the hood), and no releases
  • version/1.0 is set as the default branch
  • bonus: master branch is protected (assuming we have a way to force a merge into it from the api when needed, otherwise this isn't critical)

Versions UI

  • New icon in left gutter
  • New line under org name/project name lines to indicate active version + release. Version: 1.0.0 (Unreleased).
  • Sidebar component to list version+release tree, and main actions

Main Actions:

  • [plus icon] Version

    • brings up modal with:
      • one sentence "this is when you would use versions or what they are for" + link to versions help article
      • big toggle for is this a major or a minor version change? brief laymans sentence of when major is appropriate and when minor is appropriate
      • if user picks major, give them a big simple number selector that defaults to the standard next major version (+1 on the highest current major version)
      • if user picks minor, give them a selector to select which of the current major versions they are increasing (default to largest major), and then let the user pick a minor, defaulting the +1 on that majors largest minor value
    • route to version upon creation
  • [tag icon] Release 1.0.0

    • button shows appropriate next release version, given active version + previous releases in this version. examples:
      • given active version 1.0, no releases, next release button would show 1.0.0
      • given active version 1.0, releases 1.0.0, next release button would show 1.0.1
      • given active version 1.1, releases 1.1.0, 1.1.1, next release button would show be 1.1.2
    • brings up modal with:
      • one sentence "this is when you would use releases or what they are for" + link to releases help article.
      • release value is shown and hardcoded to the one shown on the button (1.0.0 in this example)
      • tag.message, an optional brief summary describing the release
    • do not route to release upon creation, just show success alert
  • no deleting versions or releases for now

Example Tree:

  • v2.0
    • Unreleased (navigates to editable version/2.0 branch on click)
  • v1.1
    • Unreleased (navigates to editable version/1.1 branch on click)
    • [tag icon] 1.1.1 [8m ago]
    • [tag icon] 1.1.0 [9m ago]
  • v1.0 (navigates to editable version/1.0 branch on click)
    • Unreleased [highlighted, since this would be the active version by default]
    • [tag icon] 1.0.0 [1y ago]

Migration

  • would need a migration to:
    • create version/1.0 branch for every project, branched off of master
    • make that branch the default
    • protect master if that ends up getting implemented in general

Other Thoughts

For other issues, later.

  • when a project has no releases, it is considered "unreleased". creating the first release transitions the overall project state to "released"

  • the organization project list will no longer show you projects that are unreleased AND that you have no specific permissions on (via a team or direct). the goal of this change is to reduce the noise - you will no longer see "test" type projects created by other members in the organization unless they specifically grant you or one of your teams read, write, or admin access to it (or they release it).

  • will have an option to show "unreleased" projects in the org project list as well

  • eventually should have to select one or more releases and/or versions to publish to your docs. would be represented in the docs as a dropdown to switch published versions

@marbemac

This comment has been minimized.

Copy link
Member

marbemac commented May 24, 2018

And the version/release manager sidebar pane UI:

screen shot 2018-05-24 at 11 43 53 am

@lottamus lottamus closed this Jul 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment