How to organize multiple releases/feature sets

Question

I'm the product manager for two of my company's application sets, and I've been running into some difficulties trying to manage future releases and how best to move them around. If I have version 2.2 currently in development, I have versions 2.3-2.5 already plotted out in Bugzilla. However, we are now planning on bumping a few items from 2.2 and adding a couple of other small items to make a quick release which will be called 2.3.

If I keep following my current system, I will need to update all 2.5 tasks to 2.6, 2.4 to 2.5, and 2.3 to 2.4.

I've thought about doing something like Future.10, Future.20, Future.30 - this would allow me to add in Future.15 or anything else in between. I feel like this is a problem that has been solved already, but I just don't know how. Is there a better, more generic way to plan out release order that won't require me to adjust every single future release if we add a release in or move things around?

For clarification: This question is purely about pre-development organization of several groups of features ("a release") and the best way to reorder releases without changing all tasks each time I change around the intended order.

Answer 1

One of the great things about software development releases is that you can name them whatever you want, and follow whatever pattern you want, as long as they're consistent and make sense in the context of your own workflow. You see this a lot with version numbering, where in general the numbers-between-the-dots-and-dashes (e.g. 2.4.1 or 5.4 or 1.3-patch) mean different things to different organizations.

Your specific issue of what do with "quick" releases is often addressed by using the major.minor[.build[.revision]] numbering (or just major.minor[.revision]. In this case, your project planning would be around major (2) and minor (3, 4, 5), but leave the space (in the documentation, the workflow, etc) for revisions (1, 2, etc) in between those minor releases. This is an area in which talking to your technical lead may prove helpful, because more likely than not, the developers are working in a branching model within the software version control system that would align well with what you need to do with the plan and documentation.

There are guidelines and models for specific types of versioning -- one in particular is Semantic Versioning, which has very clear guidelines for, well, all sorts of changes throughout the development process (for example, "Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.") I'm not saying you go that route (although I personally find it very useful), just that there's one of more than a few places where best practices are all spelled out and can be easily followed by workgroups.

Answer 2

I feel like this is a problem that has been solved already, but I just don't know how. Is there a better, more generic way to plan out release order that won't require me to adjust every single future release if we add a release in or move things around?

Actually, there is way and it is called one track. It means that you have only one version and you deploy always that version and you don't maintain different versions. It may sound a bit far-fetched, but actually it is possible to do. I was working for a company which had the very same issue you are having now, but they introduced a one track solution. There were lots of discussions about customers, versions, and deliveries. After a while - a couple of months - the customer understood that it was something good for him.

So my suggestion is to have only one track and deliver always from this track. In the long term it is worth it.

I haven't seen any other solution on the market. The situation with your current approach is completely understandable. Customers don't want to upgrade because of a fix or a fancy feature, because they think that it'll cost them money. Try to have a discussion with your customers and check whether a one track solution could work for them.

Answer 3

Long term plans are always subject to change - shuffling is therefore almost ineviatable. I have found from an internal perspective it's easier to talk about phases of a release - i.e. 2.2 Phase I, 2.2 Phase II etc. Semantics I know (2.2.1?, 2.2.2?), but it's easier to merge and bump phases than versions, at least its easier to get away with it with management.

However, this doesn't help for shrink wrapped products (i.e. ones that go external to clients rather than internal for business). In which case, it is sometimes easier to have a list of enhancements rather than cemented-in versions - by that I mean only linking a deliverable with a release when there is a more definite decision. These "deliverables" don't need to be left floating, they can be plotted against a timeline or a dependency list. E.G. Version 2.2 will include....bla bla bla....future releases 2.3 end of Q3 2012, 2.4 Q2 2013.....perf. enahncement 6 in dev Q2/12, win2008 version in dev Q3/12, OSX Port Q3/12, Unix Port Q4/12...etc

Of course, all this is really down the policy of your company and way/how they deliver (and to whom).

Answer 4

Don't use numbers or names that have any semantic meaning. Think about the Google Android releases. I believe one was called Ice Cream Sandwich. Using generic naming allows you to reprioritize releases without worrying about rearranging numbers. Future.10...n works, but you are still somewhat restricted by the dot number. So, try to develop with generic release naming, then when you release you can rename the release with the public release version number.

Answer 5

How about calling this quick release you mention 2.2.1? Or are there any external restrictions which do not allow you to do it?