On 5 Nov 07, at 11:20 PM 5 Nov 07, Brian E. Fox wrote:
I don't completely agree that non unique should be essentially killed.
Unless you are letting people pin to a specific snapshot instance,
(which IMO is much worse) there are no problems using the non unique
stuff. We switched to it because we were using up over 300gb / week
from
our continuous integration builds.
That stuff is easily culled, and sometimes you simply need to lock to
a version while the rest of the team converges after a hiccup. It
maybe only be a day, but a half day lost to farting around is pointless.
I think worse problems crop up when people start hand picking their
snapshot versions. This might be ok for OSS but internal commercial,
if
the latest isn't working, I want to know it and I want it fixed asap.
I've found it necessary at times to lock down and if something has
changed in the code it should be represented as something changed in
the repository. It's really not a technical feat to run a scheduled
job to clean up after snapshot production. In practical terms a window
of three days in a rapidly changing system is enough when used in
conjunction with nightly builds and team integration builds.
--Brian
-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 06, 2007 6:42 AM
To: Maven Developers List
Subject: Re: [jira] Created: (MARTIFACT-6) The deployer should detect
previous deployments of the same version and die if that's the case.
They die.
How that non unique stuff creep in should be looked at. As a short
term convenience for not having to wipe stuff out is far less
important in that you can hose an entire team. Most people nuke the
snapshots after a couple weeks but in that period no one can lock down
to anything and you potentially hose a lot of people.
If we actually get it to work in 2.0.x then some mode for allowing
that could be added but it's a terrible practice to have non-unique
snapshots. So it didn't occur to me because I tell people to never use
that feature unless they enjoy wasting their time figuring how to roll
back to something stable. It's another "the convenience doesn't out
weight the dire consequences".
On 5 Nov 07, at 9:26 PM 5 Nov 07, Brett Porter wrote:
What about non-unique-versioned snapshots?
- Brett
On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
The deployer should detect previous deployments of the same version
and die if that's the case.
------------------------------------------------------------------------
-----------------------
Key: MARTIFACT-6
URL: http://jira.codehaus.org/browse/MARTIFACT-6
Project: Maven Artifact
Issue Type: Improvement
Affects Versions: 3.0-alpha-1
Reporter: Jason van Zyl
We simply have to die because giving people an option is just going
to let them continue with their bad practices. If you let the
redeployment of released binaries then it will happen, and it will
cause problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
