GitHub/Gogs Milestones

used to plan future.

In Code Organizations (codedorg)

  • Only use version nr's e.g. 8.1.0
    • Used to organize work around a component release !!!
  • If different components make up a product & version is per product then this milestone name needs to be the same over the relevant repo's !!!
  • Milestone is used to group feature requests and bugs
  • Stories can link back to a specific milestone & issues in a repo
    • Its handy to use a query to show e.g. all bugs or e.g. JumpScale8 repo and then link this 1 query to a story card in the projorg

version nrs

  • major 1.0.0
  • minor 1.1.0
  • feature 1.1.2
  • build 1.1.2.333

There are maximum 4 milestones per codedorg repo

  • Version number 1 (nearest to today, major, minor or feature release)
  • Version number 2 (next release, major, minor or feature release)
  • Version number 3: Optional: A major or minor version number after nr 2 (only relevant when 1 or 2 are not major or minor)
  • Roadmap (always use this name!, is for future work)

DO NOT

  • Use timing milestones, e.g. may16
  • Use names

In Project organizations (projorg)

  • Milestone is a time on which a company (organization) wants to deliver something
  • This can be e.g.
    • Date to deliver a project to a customer (for a proj_... repo)
    • Just a date to put a stick in the ground, e.g. gen1_release which is pinned to a certain date
    • a certain month e.g. June
  • Each story can only belong to one milestone
  • Tasks belong to a story and as such also to a milestone
  • Only use following naming conventions (no need to specify month nr's or year nr's)
    • nov_mid
    • nov_end
    • q4
    • future
  • PLEASE be consistent with the names used otherwise presentation on a higher level layer becomes dificult.

DO NOT

  • Use version milestones, e.g. js8.1

results matching ""

    No results matching ""