Skip to content
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

Choose project versioning scheme #172

Closed
4 of 5 tasks
brylie opened this issue Jun 26, 2015 · 6 comments
Closed
4 of 5 tasks

Choose project versioning scheme #172

brylie opened this issue Jun 26, 2015 · 6 comments
Assignees
Milestone

Comments

@brylie
Copy link
Contributor

brylie commented Jun 26, 2015

Choose a scheme for project versions. Include alpha and beta releases in scheme.

Definition of done

  • Determine whether semantic versioning is suitable for this project.
  • Determine the version for the pre-release.
  • Choose how to indicate alpha, beta and release candidate in the release tag.
  • If it is, make a semantically versioned pre-release.
  • Determine the difference between pre-releases and full releases in terms of branching.
@bajiat bajiat self-assigned this Jun 29, 2015
@bajiat bajiat added this to the Sprint 6 milestone Jun 29, 2015
@bajiat
Copy link
Contributor

bajiat commented Jun 30, 2015

@brylie
Copy link
Contributor Author

brylie commented Jun 30, 2015

Additional resources

Meteor.js specific

Node.js specific

General guidelines

@bajiat
Copy link
Contributor

bajiat commented Jul 6, 2015

  • Determine whether semantic versioning is suitable for this project.
    • Semantic versioning is the standard way.
    • To be used as in the semantic versioning standard Major.Minor.Patch without leading zeros
    • 1.0.0-alpha – alpha and beta spelled out for clarity
    • Rc should also be used: 1.0.0-rc1
  • First release should be 0.1.0
  • For any milestone, we’ll need to make a stable release
  • At least one pre-release for every sprint
    • To be made on Mondays prior to new sprint planning
    • Rotating release task responsibility, working with project owner
  • Nightly builds made from development branch and not tight to official releases
  • 0.1.0 to be made from master, requires pulling from the dev branch
  • Each time we make a release, we need to decide whether it’s a minor version or a patch

@bajiat
Copy link
Contributor

bajiat commented Jul 6, 2015

Made the initial alpha release!

@bajiat bajiat added in progress and removed ready labels Jul 6, 2015
@bajiat
Copy link
Contributor

bajiat commented Jul 6, 2015

Task almost complete

  • "Determine the difference between pre-releases and full releases in terms of branching" > to be defined after we get some more understanding.
  • Need to document the versioning scheme in GitHub.

@bajiat
Copy link
Contributor

bajiat commented Jul 6, 2015

Versioning scheme documented in docs/developers/release-versioning.md

@bajiat bajiat closed this as completed Jul 6, 2015
@bajiat bajiat removed the in progress label Jul 6, 2015
brylie added a commit that referenced this issue Jan 10, 2017
Merge pull request #171 from Digipalvelutehdas/develop
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants