Comments on: Version Numbering Makes Release Planning Harder http://tynerblain.com/blog/2006/08/16/version-numbering-bad/ Software product success. Tue, 22 May 2012 20:46:27 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: How I jump to my conclusions » Handling feature-creep on your NEXT RELEASE http://tynerblain.com/blog/2006/08/16/version-numbering-bad/comment-page-1/#comment-54716 How I jump to my conclusions » Handling feature-creep on your NEXT RELEASE Mon, 21 Aug 2006 22:20:24 +0000 http://tynerblain.com/blog/2006/08/16/version-numbering-bad/#comment-54716 [...] The post was noticed at Tyner Blain, who devoted an enthousiastic post on the subject. [...] [...] The post was noticed at Tyner Blain, who devoted an enthousiastic post on the subject. [...]

]]> By: Harry Nieboer http://tynerblain.com/blog/2006/08/16/version-numbering-bad/comment-page-1/#comment-54715 Harry Nieboer Mon, 21 Aug 2006 22:10:20 +0000 http://tynerblain.com/blog/2006/08/16/version-numbering-bad/#comment-54715 Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project. The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved. The product position statement is the “mission statement” for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari). The problem statement and the product position statement are excellent tools to use in the CCB (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document. If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why! http://hij2mc.wordpress.com/2006/08/21/handling-feature-creep-on-your-next-release/ Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project.

The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved.
The product position statement is the “mission statement” for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari).

The problem statement and the product position statement are excellent tools to use in the CCB (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document.

If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why!

http://hij2mc.wordpress.com/2006/08/21/handling-feature-creep-on-your-next-release/

]]> By: Aaron Korver http://tynerblain.com/blog/2006/08/16/version-numbering-bad/comment-page-1/#comment-54696 Aaron Korver Fri, 18 Aug 2006 02:48:05 +0000 http://tynerblain.com/blog/2006/08/16/version-numbering-bad/#comment-54696 Hey Scott, I agree 100% that if you are already doing CI and have an always working product that the date thing works. But...if you already have excellent engineering practices such as those in place, then the debate about which functionality goes into a release more than likely will be a very short debate. Cheers! Hey Scott,
I agree 100% that if you are already doing CI and have an always working product that the date thing works. But…if you already have excellent engineering practices such as those in place, then the debate about which functionality goes into a release more than likely will be a very short debate.

Cheers!

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/08/16/version-numbering-bad/comment-page-1/#comment-54692 Scott Sehlhorst Thu, 17 Aug 2006 20:26:38 +0000 http://tynerblain.com/blog/2006/08/16/version-numbering-bad/#comment-54692 Aaron, thanks for reading and commenting! I completely agree about the risk. One possible approach is to manage code development with a combination of continuous development techniques and good branching practices (like those enabled with subversion). I've had the pleasure of working on and managing a couple projects that were maintained in a "release ready state", where on any given day, we could release the trunk version of the code (it passed ALL automated tests) - the only question was content. A feature is not promoted to the trunk until it passes all of its associated tests. With this approach, you can always hit the date, but occasionally have to adjust the content. Just a matter of which dials you want to turn. Aaron, thanks for reading and commenting!

I completely agree about the risk. One possible approach is to manage code development with a combination of continuous development techniques and good branching practices (like those enabled with subversion).

I’ve had the pleasure of working on and managing a couple projects that were maintained in a “release ready state”, where on any given day, we could release the trunk version of the code (it passed ALL automated tests) – the only question was content. A feature is not promoted to the trunk until it passes all of its associated tests.

With this approach, you can always hit the date, but occasionally have to adjust the content. Just a matter of which dials you want to turn.

]]> By: Aaron Korver http://tynerblain.com/blog/2006/08/16/version-numbering-bad/comment-page-1/#comment-54691 Aaron Korver Thu, 17 Aug 2006 19:32:58 +0000 http://tynerblain.com/blog/2006/08/16/version-numbering-bad/#comment-54691 Becareful with the date release numbers. If this is the "April 10th" release does it have to be released on the date April 10? What if it slips to April 11? Do you have to change the release name? From personal experience date orientated release names suggest it should be released on that date. And I think we all know that sometimes you miss dates. Becareful with the date release numbers. If this is the “April 10th” release does it have to be released on the date April 10? What if it slips to April 11? Do you have to change the release name? From personal experience date orientated release names suggest it should be released on that date. And I think we all know that sometimes you miss dates.

]]>