in reply to Re^3: Find your own monastery: "Perl 6" is not Perl, and Perl is not a Dinosaur
in thread Find your own monastery: "Perl 6" is not Perl, and Perl is not a Dinosaur
While I don't, the project managers do tie features to specific versions - based on customer requirements. And, at least in the industry I work in, the major version numbers are tied to the project phases. Ideally, we have exactly 5 releases: 1.0.0 (simulation release) through 5.0.0 (production release). More often, we make minor releases as the customer requirements are "refined", and fix releases resulting from "contact with the real world"
FYI, when a customer of ours plans a new product - or new version of a product - they set the schedule. Then they write version 1.0.0 of their requirements and issue a "Request for Quote" (RFQ) to potential suppliers, including the schedule and version 1.0.0 requirements. Then, our project managers review the requirements, get estimates from product development (my division) and make a bid recommendation to higher level management, who decide whether to bid and the actual pricing. If the customer accepts our bid, the various product development managers are directed to assign teams to design and implement a control module based on the "core subset" of the version 1.x requirements for delivery by the Phase 1 due date. (I say 1.x because the customer inevitably continues to "refine" their requirements after the RFQ package is sent out.) Once my team (software) releases 1.0.0 to validation, we start on Phase 2 software.
|
|---|