Return-Path: 
 <ivy-user-return-6181-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-ivy-user-archive@www.apache.org
Received: (qmail 88834 invoked from network); 1 Dec 2009 12:04:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 1 Dec 2009 12:04:07 -0000
Received: (qmail 46695 invoked by uid 500); 1 Dec 2009 12:04:06 -0000
Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org
Received: (qmail 46628 invoked by uid 500); 1 Dec 2009 12:04:05 -0000
Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@ant.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@ant.apache.org>
List-Post: <mailto:ivy-user@ant.apache.org>
List-Id: <ivy-user.ant.apache.org>
Reply-To: ivy-user@ant.apache.org
Delivered-To: mailing list ivy-user@ant.apache.org
Received: (qmail 46615 invoked by uid 99); 1 Dec 2009 12:04:04 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 12:04:04 +0000
X-ASF-Spam-Status: No, hits=-2.6 required=5.0
	tests=BAYES_00
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 12:03:58 +0000
Received: from isper.nabble.com ([192.168.236.156])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists@nabble.com>)
	id 1NFRSD-0006Ks-VN
	for ivy-user@ant.apache.org; Tue, 01 Dec 2009 04:03:37 -0800
Message-ID: <26590707.post@talk.nabble.com>
Date: Tue, 1 Dec 2009 04:03:37 -0800 (PST)
From: Juha Ranta <juha.ranta@iki.fi>
To: ivy-user@ant.apache.org
Subject: Re: Versioning Best Practices?
In-Reply-To: <fc59cc3a0911292021i7998cc9fy1d886dce646a81b4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: juha.ranta@iki.fi
References: <fc59cc3a0911232234s46b9ceabp2480294f44e553cd@mail.gmail.com>
 <26513407.post@talk.nabble.com>
 <fc59cc3a0911292021i7998cc9fy1d886dce646a81b4@mail.gmail.com>



ipsi wrote:
> 
> Hey everyone, thanks for all your responses.
> 
> Seems like timestamps are pretty common. I assume you set the
> timestamp with Ant, as part of the build? Not sure exactly how to do
> that, but I don't image it will be hard. Also, do you clean out your
> local repositories at all? Or does it just keep on building up? Or do
> you have good enough unit tests that you don't *need* to create
> artifacts very often?
> 

Just to clarify terms, I think that that in the Ivy tutorial and default
settings, local repository is developer's private repository in his own
workstation. In this case, the developer can himself clean the repository
when he wants to make sure he gets more official builds while doing resolve.

But I assume you mean a repository that is perhaps shared by more
developers, such as a repository of continuous integration builds. Well...
in our case, I know we should clean that somehow, but so far we haven't had
problems with the disk space. :)

As for setting timestamp, you can use Ant's tstamp task to get the time in a
property and then use that property in publish task such as: <publish
revision="1.2.${timestamp}" .. /> 




> Keith: Thanks for the hint about changing="true", I'll give it a shot
> as soon as I'm back on our Ivy-using project. I also like the idea of
> using latest.${ivy.publication.status}, but I don't suppose you know
> if I can limit the version number to a range as well? e.g. limit a
> *release* to the latest *release* in the range [1.0.0,1.1.0[ ? While
> it *shouldn't* matter for now, I could see a situation where a client
> is on Version X of the software, which uses the 1.0.* branch, but
> another client is on Version Y of the software, which includes the
> 1.1.* branch - with the 1.1.* branch introducing breaking changes. As
> such, maintenance work may be needed on the 1.0.* branch (because the
> client is still using it and willing to pay for changes), but I don't
> want the clients using the 1.0.* branch picking up the release
> versions of the 1.1.* branch (because then everything would break).
> Does that make sense?
> 

I'm not sure, but I figure out you want to somehow get the latest module
with the status release from the 1.0.* branch? If you set the branch
attribute in your published ivy.xmls, you can get the latest release from
that branch with something like <dependency rev="latest.release"
branch="1.0" .. />

There was some discussion about this in a recent thread about branches on
this list. 

Juha
-- 
View this message in context: http://old.nabble.com/Versioning-Best-Practices--tp26491097p26590707.html
Sent from the ivy-user mailing list archive at Nabble.com.