Alternatively, you could apply similar
attributes to a Build (e.g. “Iteration Build”, “Product
Release Build”).
At one client, our current practice is to
use the term “Milestone Build” to differentiate it from the “CI
builds” that we’re constantly doing on the Continuous Integration
machine. Only Milestone Builds get full system test cycles, and the results
are used to measure progress against the iteration objectives. I’m
not suggesting we universalize this approach, but it does seem to be working.
With this terminology, a Release always
means what it implies, that a particular build was released into the wild.
Nate Oster
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
Sent: Friday, September 08, 2006
12:26 PM
To: Eclipse Process Framework
Project Developers List
Subject: Re: [epf-dev] term
definition
I'd add that in continuous-integration type of
environments, builds are created daily (and more often than that), so I don't
like the definition of build being an executable provided at the end of an
iteration.
I'd
prefer to say that releases are ready at the end of iterations, and classify
them according to "completeness" (e.g., Product Release, to align
with the name of the Milestone at the end of Transition phase).
Cheers,
Ricardo Balduino
Senior Software Engineer
IBM - RUP Team | EPF Committer
www.ibm.com/rational
www.eclipse.org/epf
|
"VAIDYA Kirti"
<KVAIDYA@xxxxxxxxxxxx>
Sent
by: epf-dev-bounces@xxxxxxxxxxx
09/07/2006 02:00 PM
|
Please
respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
|
|
|
To
|
<epf-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
Re: [epf-dev] term definition
|
|
I
think a Build need not be an executable or even an operational integration,
e.g. Builds that are libraries or partial integrations. Also, there will be
multiple builds but 1 release per iteration.
How about:
"A build is an aggregation of related
compiled code segments that can be managed as a unit"?
"A release is an executable aggregation of
related compiled code segments and corresponding supporting documentation that
can be published as a unit."
Releases could be further classified as internal,
external, iteration, and project end. I have also seen releases that were
external at iteration milestones, esp in product development.
--------------------------
Sent from my BlackBerry Wireless Handheld
-----Original Message-----
From: epf-dev-bounces@xxxxxxxxxxx
To: epf-dev@xxxxxxxxxxx
Sent: Thu Sep 07 16:16:17 2006
Subject: [epf-dev] term definition
Hi,
while preparing some PM content for burndown and
phases, I needed to decide on two terms. Here are my suggestions.
"Build" (commonly an iternal executable
after each iteration, occassional external for verification purposes)
"Release" (term for external release
when the project transitions out... could be pre, beta or production release)
I suggest removing the term "release" in
OpenUP after each iteration and replace it with "build".
Thoughts? Agreement?
Joe
Confidentiality Statement:
This message is intended only for the individual
or entity to which it is addressed. It may contain privileged, confidential
information which is exempt from disclosure under applicable laws. If you are
not the intended recipient, please note that you are strictly prohibited from
disseminating or distributing this information (other than to the intended
recipient) or copying this information. If you have received this communication
in error, please notify us immediately by return email.
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
