Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • bob.extension bob.extension
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 5
    • Issues 5
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • bobbob
  • bob.extensionbob.extension
  • Issues
  • #6
Closed
Open
Issue created Jan 25, 2016 by André Anjos@andre.anjos💬Owner

bob_new_version.py misses a good "default" for version numbers

Created by: anjos

This is a very useful script. It would be an awesome addition if we could have either a flag (or the absence of any) to implement a "default" version releasing.

How would that work?

  1. bob_new_version.py reads the file version.txt and figures out what is the "next" release.
  2. It sets the stable version to that value (minus the aX, bX or rcX complements, of course).
  3. It sets the latest version to be the value in item 2 above + one minor patch number. For example, if the value on version.txt was '2.0.5b0', then stable = 2.0.5 and latest = 2.0.6b0.

This way it would be possible to issue something like:

$ ./bin/bob_new_version.py --default-release

And get the ball rolling. This would also allow us to batch release a number of packages at once, w/o taking into consideration differences between release numbers.

If a new API release is on the horizon, the developer must updated "version.txt" so that the file version.txt is correctly preset (e.g., to 2.1.0b0). This way bob_new_version.py --default-release will do the right thing next time.

@siebenkopf: What do you think?

Assignee
Assign to
Time tracking