Uploaded image for project: 'Bitbucket Cloud'
  1. Bitbucket Cloud
  2. BCLOUD-11528

Make milestones and versions more meaningful (BB-13737)



    • Feedback Policy:

      Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.


      Bitbucket supports such features as milestones and versions, but essentially those are just labels/tags just like components as you can do little with them. That would be nice if milestones and versions could reflect their actual terms.

      I could see a version having at least two states:

      • Active / In Progress
      • Released

      and milestones having different states as well:

      • Active / In Progress
      • Reached
      • Missed / Delayed

      A milestone's state could be even provided automatically if there was a connection between them and actual dates. I don't really know how other people use milestones, but I myself typically name them like "2015-10-15" and consider it as a milestone's deadline.

      Another thing is that there is no need in two such entities. You can think about a milestone as a date of a release. Therefore, that would be enough if there was such a thing as version (release) and a specific date assigned to it. A version is not necessarily a production release that you deliver, say, once a quarter, but could be any internal release as well.

      The problems that currently exist with milestones and versions how they are implemented in Bitbucket:

      • They are basically tags and nothing else
      • They are directly connected in real life, but there is no way to make that connection between them in Bitbucket
      • If you treat them as actual versions and milestones, you have to do a lot of manual work and can introduce inconsistency in your issue tracker as you can easily assign a version and a milestone to an issue which are disconnected and not supposed to come along

      That would be enough to have the only entity in fact: Version (or Release), and make it able to assign some due date to it. And considering that date, Bitbucket could automatically show the current status of that version.

      PS I understand that you are trying to keep Bitbucket as simple as possible, and make customers to eventually migrate to Jira when Bitbucket functionality becomes insufficient might also be a final goal. However, to be fair, this particular issue brings sort of inconsistency to the system and probably even makes the user experience worse. Also, I personally would prefer paying to Bitbucket if I needed to introduce more than 5 users for a project instead of paying for Jira because Bitcucket's UI is still neat whereas Jira is incredibly overwhelming to me. Please just consider these points as well.




            csbubbles Maxim Novikov
            2 Vote for this issue
            3 Start watching this issue