commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Grobmeier" <grobme...@possessed.de>
Subject Re: [VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!
Date Thu, 27 Jul 2006 09:52:01 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

not sure, but why don't you put the desired snapshot in a local repository?
- - Chris

Vincent Massol wrote:
> 
>> -----Original Message-----
>> From: Mario Ivankovits [mailto:mario@ops.co.at]
>> Sent: jeudi 27 juillet 2006 09:01
>> To: Jakarta Commons Users List
>> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the
>> m1 snapshot repo!
>>
>> Hi Vincent!
>>> Someone just told me that Cargo is not building anymore because the
>> 20060719
>>> snapshot is no longer there! I checked and it's not there...
>>>
>> Yes, the automated build process only keeps a week of builds.
>> As a quick fix I updated the -SNAPSHOT to point to the build from
>> 26-July-2006 (its a copy for now, so wont disappear)
>> Could you change your build to use the -SNAPSHOT?
> 
> I'll try to do this but it's only marginally better than before. I don't
> want the cargo build to try every day to use a new snapshot if there's one.
> That would be good for a tool like Gump but I don't want Cargo to track the
> VFS snapshots. I want to decide what version I use and I want to control
> when I want to move to a new version. Otherwise it's simply going to be too
> much maintenance work.
> 
> So what I really need is a version of VFS that is not going to go away (even
> a timestamped version is fine but don't delete it. Maybe simply put it in
> the Maven 1 Release Repository so that it doesn't get deleted. Call it
> 1.0-200607271124 for example.
> 
> BTW on a related note I think the versioning scheme for VFS is not correct.
> I think it should have the target version number in the file name. Instead
> of "SNAPSHOT", it should be "1.0-SNAPSHOT". Imagine that you start working
> on a 2.0 branch for example.
> 
> The best is of course for you to release a 0.1 version. VFS had been going
> on for what, a year? More? It's really a bad practice to not release a
> framework for such a long period of time. I understand the version (like the
> API is not stabilized, etc) but that's not right. What you can be sure of is
> that if a framework is late in releasing versions then people are going to
> use snapshot versions as if they were releases and they'll complain the same
> if something changes, etc.
> 
> This leads me to the conclusion that the VFS project doesn't want any
> serious users at this point in time. Otherwise you would have released a
> version. You're only interested in people doing experiments. Thus as Cargo
> has been released several times already I don't think it should use VFS.
> Right now I've kept the usage of VFS for our unit tests (not production
> code) and unfortunately this is going to prevent us from using it for our
> production code till there's a first version (even a 0.1 version).
> 
>> Eventually, later, we will automatically set this snapshot to always the
>> latest build.
>>
>> Which again might bring up some problems for you, as then the build can
>> fail due to internal VFS changes, though, that happened not that often -
>> not to say, it happened never before ;-)
>>
>>> Luckily I had not gone too far in using VFS and it can be
>>> removed quite easily but that would be a real pity as I'm starting to
>> like
>>> it...
>>>
>> Don't jump the gun, I'll help you :-)
>>
>> Sorry for the inconvenience!
> 
> Thanks for your help Mario, real appreciated! Now I've come to the
> conclusion that the only way to progress is to get a 0.1 VFS release out.
> Just release whatever you have in SVN trunk and call it 0.1.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 
> 
> 	
> 
> 	
> 		
> ___________________________________________________________________________ 
> Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! 
> Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences.

> http://fr.answers.yahoo.com 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEyIzBkv8rKBUE/T4RApIxAKCOZnBkh9bn/g/ih+PIxq4jRpnQ/ACcC4h0
3UpsESH/jD5J/b1k+nOsLrE=
=ZHQN
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message