Is there any correlation between versioning and milestones?

Question

A lot of OS projects I know (I am PHP developer) uses versions as milestones, but is this the best way? Should milestones mean something in process of project iterations (meaningfull names)? Are there any rules? Or maybe its totally subjective?

Answer 1

Well yes it means that you have completed enough work in the iterations to release something useful. A milestone generally means that you have acheived something of more significance than just the end of an iteration. I would use meaningful names yes.

Answer 2

Version numbers are convenient because you can instantly take any two versions and see which one is the newer of the two. It is always going to be subjective to a degree, because who is to say what feature(s) or bug fix(es) constitutes a milestone?

The scheme I like is x.y.z where x is the major release number, y is the minor release number, and z is the build number. Major release would mean either a rewrite, overhaul, or major new functionality is introduced. Minor release would mean a significant bug fix, or number of small feature improvements or bug fixes. Build number would be precisely that - the number of builds.

Answer 3

Like the old adage goes, "The wonderful thing about standards are that there are so many to choose from." I can't tell you how I would do it for a PHP project, but I can tell you the approach that we use for our shop - which is a .NET shop.

We use a fairly traditional four-part versioning system, with each part of the version representing something different. For example:

Major.Minor.Revision.Build

Obviously, each of those would be a number. These four parts are, for us, preordained by Microsoft. Let me walk you backwards through the stack, as to how we justify each:

• Build - Automatically incremented in our shop. This indicator is like a unique identifier for a build, as it is provided by the compiler.
• Revision - We reserve this for a release that will not break compatibility. Exposed interfaces are preserved and third party implementations will presumably run intact without modifications.
• Minor - This is a release that generally introduces new functionality, changes existing functionality, and runs a higher risk of breaking compatibility.
• Major - Large scale changes that involve large rewrites, large new feature sets, and fundamentally deviate from the previous codebase.

Where do Milestones come in to play? They are project goals for us. Milestones are determined prior to project kickoff and represent points where an expected progress level should be met. It is largely used to introduce business users to functionality before a release and to monitor the overall delivery schedule of the release. We additionally apply a label in our version control for each milestone to help to easily identify the milestone if it needs to be manually built for any reason.

In our shop, the content of the milestone is more important than what it is called. Why? Complex milestones cannot be easily named in a way to convey meaning when there are multiple reasons that it is a milestone. We put milestones on the calendar and wiki with a description of what is expected to be achieved in it.

Like I mentioned earlier, I am sure that you will get some other "standards", as well. The goal is to find the process that works for you and your team, and to stick to it.

Answer 4

Can u give me some simple (made up) example of milestone names?

Answer 5

In our development process, versions and milestones are something different. One of our standard milestones is the release. That has, of course, a version. But to me, a milestone is somthing in the future, something that I have to plan for. A version is coupled to a release, so it is something that is in the past.

Our standard milestone scheme is based on a company wide project management standard. We have

• S-Gate: Specified
• A-Gate: Available
• V-Gate: Verified
• R-gate: Released

For iterative development, we basically repeat this cycle. From A to V gate is the alpha phase, from V to R is beta phase. For bigger projects we add milestones that relate to specific feature sets being completed.

The reason we use it is mainly that all projects are reported according to this scheme, and it is always good practice to present information to the managament in a way they are familiar with ;-)

Answer 6

You're talking about at least two unrelated things. There are source code control and project milestones. They're related, but they aren't the same thing. Plus, there's also software development work itself, which is related to source code and project milestones, but it's also different.

Here's an approach based on Scrum. It has three unrelated things which could be numbered or named.

First, there's the software development work.

1. We have sprints to build stuff. These can be numbered, but they usually have names. Names like "Bulk Loading Part 1", or "Refactor workbook library" or "Add Sales Demo Data Fixture" or things like that.

2. We have releases to release stuff. These could be numbered (based on the SVN revision, or based on our internal "compatibility version", but they usually have names. "First Release for Customer X", or "Bug Fix For This" or "Upgrade to That" or something meaningful.

Second, there's source code control. For this, we have some internal version/revision tracking that has little to do with sprints and releases.

1. SVN has repository version numbers. This increments with each checkin. Some weeks, there's a checkin every day. Some weeks, there's only a few "big" checkins.

2. We have a major.minor version number that we update manually to show compatibility. Some applications move from 1.1 to 1.2 because something small changed, but the database and the API's are the same. Other applications move from 2.3 to 3.1 because either the database or the API (or both) changed in some incompatible way and we need to do schema migration and possibly notify customer of changes to the REST client interface.

Third, there's project planning.

Our project planning milestones include our release schedule. However, the project milestones have include other things which have little to do with software. Milestones include things like "Signing the new hosting agreement", for example, or "Get Customer X Test Data". These aren't versions or releases or sprints or anything.

"Are there any rules?" Yes. Read up on Scrum for a good set of rules.

This is not a single thing. It's two (or three) things.