ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nascif Abousalh-Neto" <Nascif.AbousalhN...@sas.com>
Subject RE: Status Promotion Best Practice?
Date Tue, 18 Sep 2007 18:01:39 GMT
Hi Gilles,

Thanks for your reply. I would agree with your assessment (that they
should be handled separately) if dependency management was completely
transparent to build promotion. But I don't think this is case, since
there is a "status" concept in Ivy that can be used to select
dependencies. Isn't  "latest.<status>" a way to select a version?

In that case, I would think that the status workflow - which to me is
how build promotion is reflected in the Ivy system - becomes an
important component of the overall dependency management strategy. Which
is why I am looking for Ivy commands or best practices to reflect that
relationship.

To be more precise: I think that Ivy has the assumption that a module is
published with its final status and that it will never change. So once I
decide a module is of status, say "milestone", it should stay like that
from that point on.

But what if the status was defined by a different team - say, after
testing or doing some kind of Q&A? That team would retrieve the artifact
from the repository, so it must have been published first. Then -
assuming all tests passed - what should it do, re-publish under the same
version but with the new status, or publish a completely new version -
even though content and dependencies are the same?

Maybe my understanding of how status should be used is not correct,
which is why I am asking about "best practices" and its recommended use.
But I really would like to be able to allow our developers to select
versions based on their build promotion status and would appreciate any
suggestion or shared experience on how that can be accomplished. 


Thanks,
  Nascif

-----Original Message-----
From: Gilles Scokart [mailto:gscokart@gmail.com] 
Sent: Tuesday, September 18, 2007 5:56 AM
To: ivy-user@incubator.apache.org
Subject: RE: Status Promotion Best Practice?


Hmm, it seems that no one has a good response to your questions.  I
don't have it neither, but here is what I think about it:

Maybe the build promotions management and dependency management are two
different things that should be handled separately.

For instance, you can have a file or a database somewhere telling which
version has passed this step of your development lifecycle.

You can see build promotions has a workflow where dependency management
has maybe nothing to do.

Of curse, build promotions and dependency management have to share
something: the version number, artefacts, and maybe some other
meta-data.  

They are meeting together around the repository management, which in
turn might require a third dedicated tool.


I have to admit that I have no idea if I'm right or not...  It was just
my 2 cents.

Gilles 


> -----Original Message-----
> From: Nascif Abousalh-Neto [mailto:Nascif.AbousalhNeto@sas.com]
> Sent: vendredi 14 septembre 2007 19:34
> To: ivy-user@incubator.apache.org
> Subject: Status Promotion Best Practice?
> 
> A question about using status during the development cycle, in a a 
> scenario where different teams are responsible for the status 
> "promotion".
> 
> Let's say a development team publishes an artifact with status X, 
> indicating a basic level of unit testing.
> Then a testing team retrieves this artifact (probably using 
> rev="latest.X"), runs a suite of integration tests, and decides to 
> "bless" the artifact with the next status value, say Y.
> 
> How can that process be implemented? It seems the testing team would 
> have to do another publish or another deliver (not sure which one), 
> keeping the existing version but changing the status to Y.
> 
> Does that makes sense? I have the feeling that this operation should 
> be common enough to have a shortcut, perhaps something like 
> <ivy:promote newstatus="Y" .../>
> 
> Anybody out there doing something similar?
> 
> Thanks,
>   Nascif


Mime
View raw message