On 6 Nov 07, at 4:58 AM 6 Nov 07, Brian E. Fox wrote:
I agree with that. I think the point is that both are valid use cases.
Problems in both can stop teams in their tracks, but snapshots
overflowing on your machine is really a maintenance issue where not
providing a path to use is something we're allowing which I think is
bad. For everything little "freedom" we allow it is an avenue to do
something that will lead to an instability. I just think this is
unnecessary. When it does go wrong it's bad when a bunch of those
"freedoms" kick in to bite you in the ass in the same week, which is
usually the case, it's just hard to defend Maven's position as a
standard, reliable build tool. In every case there is a decision point
like this we should take the path of least potential hindrance to a
teams productivity.
Although if my repo manager supported the cleanup, I would more than
likely use uniqueversions even if I didn't intend to use them, just in
case.
-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 06, 2007 8:39 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.
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]
---------------------------------------------------------------------
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]
