You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2007/11/06 06:26:25 UTC
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
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 - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Brett Porter <br...@apache.org>.
On 06/11/2007, at 4:42 PM, Jason van Zyl wrote:
> 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".
-1 to this.
As much as I continue to recommend the same thing, I know people use
these in different ways (eg, just having the latest 500mb EAR file
available in the repository) that would make it silly to remove the
functionality under the assumption that we know better what their
requirements are.
You already have to find the setting buried in the documentation,
let's just bury the associated explanation as to why you should use
pinnable snapshots right on top of it.
Cheers,
Brett
>
> 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 - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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.
As the creator of the Iron fist of Maven (enforcer) I can hardly argue
with that logic. Touche.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Jason van Zyl <ja...@maven.org>.
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:jason@maven.org]
> 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:jason@maven.org]
>> 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 - brett@apache.org
>>> Blog: http://www.devzuz.org/blogs/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I agree with that. I think the point is that both are valid use cases.
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:jason@maven.org]
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:jason@maven.org]
> 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 - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Jason van Zyl <ja...@maven.org>.
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:jason@maven.org]
> 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 - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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.
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.
--Brian
-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org]
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 - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
Posted by Jason van Zyl <ja...@maven.org>.
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 - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org