You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repo-maintainers@maven.apache.org by Mark Diggory <md...@MIT.EDU> on 2008/03/25 22:55:57 UTC
replacing one jar...
Well, we've done it again,
we have a release almost out the door and encounter an issue with one
of the jars that is already rsync'd into the central repo for our
project... All our jars are on a syncronous release cycle at the
moment and share the same parent version. we're cutting our first
major release that uses maven and its 1.5.0. We havn't announced or
had any users try to install it yet. Is there any way to get a copy
of this jar with the fix in before the artifact starts being used?
Is this something that if I opened a JIRA request, that is could be
done int he central repo, again this a brand new jar that just came
in yesterday.
Our problem is that were trying to relese 1.5.0 to our community and
they are going to get real confused if instead we have to start
talking about 1.5.1 be fore it even got out the door.
thanks for any advice,
Mark
~~~~~~~~~~~~~
Mark R. Diggory - DSpace Developer and Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
Re: replacing one jar...
Posted by Mark Diggory <md...@MIT.EDU>.
After all this and a discussion with my fellow commiters in the
dspace group, our decision is to live with the release and prepare a
maintenance release across all the projects again in the near future
(3 weeks). Because we don't expect this to be the largest of our
problems once the project is out in the wild and really put to the test.
thanks for the consideration however. I'm sure countless others have
come to the same conclusion or your policies wouldn't have stood the
test of time ;-)
cheers,
Mark
On Mar 25, 2008, at 4:54 PM, Brett Porter wrote:
> yes
>
> On 26/03/2008, at 10:42 AM, Mark Diggory wrote:
>
>> Can that new version be a build dated number like
>> 1.5.0-20080325.jar ?
>>
>> On Mar 25, 2008, at 4:28 PM, Brett Porter wrote:
>>
>>> Get everything right on your end (including deleting the 1.5.0
>>> JAR) then let us know and we can pull the trigger.
>>>
>>> On 26/03/2008, at 10:06 AM, Mark Diggory wrote:
>>>
>>>> what would be the process for updating that one pom file then?
>>>>
>>>> On Mar 25, 2008, at 4:04 PM, Brett Porter wrote:
>>>>
>>>>>
>>>>> On 26/03/2008, at 9:50 AM, Mark Diggory wrote:
>>>>>
>>>>>>>
>>>>>>> Maybe 1.5.0.1 is better then. If you haven't announced it
>>>>>>> there might be a good chance it's not in use, but you never
>>>>>>> know.
>>>>>>
>>>>>> What are the chances of doing something like releasing a
>>>>>> second version of the bad jar (1.5.0-fix) and update our
>>>>>> parent pom so that its dependency management uses that version
>>>>>> in the build process instead?
>>>>>>
>>>>>> http://repo1.maven.org/maven2/org/dspace/dspace-parent/1.5.0/
>>>>>> dspace-parent-1.5.0.pom
>>>>>
>>>>> That should be possible - though you bear the same risks at
>>>>> least it will be easier to diagnose people who have the old JAR
>>>>> vs the new one.
>>>>>
>>>>> - Brett
>>>>>
>>>>> --
>>>>> Brett Porter
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
Re: replacing one jar...
Posted by Brett Porter <br...@apache.org>.
yes
On 26/03/2008, at 10:42 AM, Mark Diggory wrote:
> Can that new version be a build dated number like 1.5.0-20080325.jar ?
>
> On Mar 25, 2008, at 4:28 PM, Brett Porter wrote:
>
>> Get everything right on your end (including deleting the 1.5.0 JAR)
>> then let us know and we can pull the trigger.
>>
>> On 26/03/2008, at 10:06 AM, Mark Diggory wrote:
>>
>>> what would be the process for updating that one pom file then?
>>>
>>> On Mar 25, 2008, at 4:04 PM, Brett Porter wrote:
>>>
>>>>
>>>> On 26/03/2008, at 9:50 AM, Mark Diggory wrote:
>>>>
>>>>>>
>>>>>> Maybe 1.5.0.1 is better then. If you haven't announced it there
>>>>>> might be a good chance it's not in use, but you never know.
>>>>>
>>>>> What are the chances of doing something like releasing a second
>>>>> version of the bad jar (1.5.0-fix) and update our parent pom so
>>>>> that its dependency management uses that version in the build
>>>>> process instead?
>>>>>
>>>>> http://repo1.maven.org/maven2/org/dspace/dspace-parent/1.5.0/dspace-parent-1.5.0.pom
>>>>
>>>> That should be possible - though you bear the same risks at least
>>>> it will be easier to diagnose people who have the old JAR vs the
>>>> new one.
>>>>
>>>> - Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: replacing one jar...
Posted by Mark Diggory <md...@MIT.EDU>.
Can that new version be a build dated number like 1.5.0-20080325.jar ?
On Mar 25, 2008, at 4:28 PM, Brett Porter wrote:
> Get everything right on your end (including deleting the 1.5.0 JAR)
> then let us know and we can pull the trigger.
>
> On 26/03/2008, at 10:06 AM, Mark Diggory wrote:
>
>> what would be the process for updating that one pom file then?
>>
>> On Mar 25, 2008, at 4:04 PM, Brett Porter wrote:
>>
>>>
>>> On 26/03/2008, at 9:50 AM, Mark Diggory wrote:
>>>
>>>>>
>>>>> Maybe 1.5.0.1 is better then. If you haven't announced it there
>>>>> might be a good chance it's not in use, but you never know.
>>>>
>>>> What are the chances of doing something like releasing a second
>>>> version of the bad jar (1.5.0-fix) and update our parent pom so
>>>> that its dependency management uses that version in the build
>>>> process instead?
>>>>
>>>> http://repo1.maven.org/maven2/org/dspace/dspace-parent/1.5.0/
>>>> dspace-parent-1.5.0.pom
>>>
>>> That should be possible - though you bear the same risks at least
>>> it will be easier to diagnose people who have the old JAR vs the
>>> new one.
>>>
>>> - Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
Re: replacing one jar...
Posted by Brett Porter <br...@apache.org>.
Get everything right on your end (including deleting the 1.5.0 JAR)
then let us know and we can pull the trigger.
On 26/03/2008, at 10:06 AM, Mark Diggory wrote:
> what would be the process for updating that one pom file then?
>
> On Mar 25, 2008, at 4:04 PM, Brett Porter wrote:
>
>>
>> On 26/03/2008, at 9:50 AM, Mark Diggory wrote:
>>
>>>>
>>>> Maybe 1.5.0.1 is better then. If you haven't announced it there
>>>> might be a good chance it's not in use, but you never know.
>>>
>>> What are the chances of doing something like releasing a second
>>> version of the bad jar (1.5.0-fix) and update our parent pom so
>>> that its dependency management uses that version in the build
>>> process instead?
>>>
>>> http://repo1.maven.org/maven2/org/dspace/dspace-parent/1.5.0/dspace-parent-1.5.0.pom
>>
>> That should be possible - though you bear the same risks at least
>> it will be easier to diagnose people who have the old JAR vs the
>> new one.
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: replacing one jar...
Posted by Mark Diggory <md...@MIT.EDU>.
what would be the process for updating that one pom file then?
On Mar 25, 2008, at 4:04 PM, Brett Porter wrote:
>
> On 26/03/2008, at 9:50 AM, Mark Diggory wrote:
>
>>>
>>> Maybe 1.5.0.1 is better then. If you haven't announced it there
>>> might be a good chance it's not in use, but you never know.
>>
>> What are the chances of doing something like releasing a second
>> version of the bad jar (1.5.0-fix) and update our parent pom so
>> that its dependency management uses that version in the build
>> process instead?
>>
>> http://repo1.maven.org/maven2/org/dspace/dspace-parent/1.5.0/
>> dspace-parent-1.5.0.pom
>
> That should be possible - though you bear the same risks at least
> it will be easier to diagnose people who have the old JAR vs the
> new one.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
Re: replacing one jar...
Posted by Brett Porter <br...@apache.org>.
On 26/03/2008, at 9:50 AM, Mark Diggory wrote:
>>
>> Maybe 1.5.0.1 is better then. If you haven't announced it there
>> might be a good chance it's not in use, but you never know.
>
> What are the chances of doing something like releasing a second
> version of the bad jar (1.5.0-fix) and update our parent pom so that
> its dependency management uses that version in the build process
> instead?
>
> http://repo1.maven.org/maven2/org/dspace/dspace-parent/1.5.0/dspace-parent-1.5.0.pom
That should be possible - though you bear the same risks at least it
will be easier to diagnose people who have the old JAR vs the new one.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: replacing one jar...
Posted by Mark Diggory <md...@MIT.EDU>.
On Mar 25, 2008, at 3:44 PM, Brett Porter wrote:
> On 26/03/2008, at 9:37 AM, Mark Diggory wrote:
>
>>
>> On Mar 25, 2008, at 3:23 PM, Brett Porter wrote:
>>
>>> Can you announce the release with this listed as a known issue
>>> and then do 1.5.1 to correct the problem?
>>
>> We're discussing it now... but... we'd rather have the issue
>> solved before we announce the release at a rather large conference
>> next week.
>>
>>> As much as I want to say you could do this, the repercussions of
>>> potentially having someone think they have the release, but
>>> instead have this JAR, are probably longer lasting.
>>
>> Actually, for us the repercussions of our users getting the
>> release jar are far worse...
>
> Maybe 1.5.0.1 is better then. If you haven't announced it there
> might be a good chance it's not in use, but you never know.
What are the chances of doing something like releasing a second
version of the bad jar (1.5.0-fix) and update our parent pom so that
its dependency management uses that version in the build process
instead?
http://repo1.maven.org/maven2/org/dspace/dspace-parent/1.5.0/dspace-
parent-1.5.0.pom
>>
>>
>> and what I'm really learning from this is that we don't want to
>> release into the central repo until we've vetted what was produced
>> as artifacts more thoroughly... in fact, we probibly want to
>> maintain our own release repo in such a way that we only allow
>> copies to be rsynced to the central repo when we are really sure
>> the release has worked and is stable for our users, only really
>> using the central repo as a mirror/archive
>>
>> Is there a way we can have the rsync controlled manually? so that
>> things only go central when we want them to?
>
> We generally use the stage plugin to copy from a staged release
> repository (where voting/testing occurs) to the Apache repository
> (which is then sync'd). You can check out the Maven release
> instructions for how to do this.
Ok, I will take a look at it...
-Mark
Re: replacing one jar...
Posted by Brett Porter <br...@apache.org>.
On 26/03/2008, at 9:37 AM, Mark Diggory wrote:
>
> On Mar 25, 2008, at 3:23 PM, Brett Porter wrote:
>
>> Can you announce the release with this listed as a known issue and
>> then do 1.5.1 to correct the problem?
>
> We're discussing it now... but... we'd rather have the issue solved
> before we announce the release at a rather large conference next week.
>
>> As much as I want to say you could do this, the repercussions of
>> potentially having someone think they have the release, but instead
>> have this JAR, are probably longer lasting.
>
> Actually, for us the repercussions of our users getting the release
> jar are far worse...
Maybe 1.5.0.1 is better then. If you haven't announced it there might
be a good chance it's not in use, but you never know.
>
>
> and what I'm really learning from this is that we don't want to
> release into the central repo until we've vetted what was produced
> as artifacts more thoroughly... in fact, we probibly want to
> maintain our own release repo in such a way that we only allow
> copies to be rsynced to the central repo when we are really sure the
> release has worked and is stable for our users, only really using
> the central repo as a mirror/archive
>
> Is there a way we can have the rsync controlled manually? so that
> things only go central when we want them to?
We generally use the stage plugin to copy from a staged release
repository (where voting/testing occurs) to the Apache repository
(which is then sync'd). You can check out the Maven release
instructions for how to do this.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: replacing one jar...
Posted by Mark Diggory <md...@MIT.EDU>.
On Mar 25, 2008, at 3:23 PM, Brett Porter wrote:
> Can you announce the release with this listed as a known issue and
> then do 1.5.1 to correct the problem?
We're discussing it now... but... we'd rather have the issue solved
before we announce the release at a rather large conference next week.
> As much as I want to say you could do this, the repercussions of
> potentially having someone think they have the release, but instead
> have this JAR, are probably longer lasting.
Actually, for us the repercussions of our users getting the release
jar are far worse...
and what I'm really learning from this is that we don't want to
release into the central repo until we've vetted what was produced as
artifacts more thoroughly... in fact, we probibly want to maintain
our own release repo in such a way that we only allow copies to be
rsynced to the central repo when we are really sure the release has
worked and is stable for our users, only really using the central
repo as a mirror/archive
Is there a way we can have the rsync controlled manually? so that
things only go central when we want them to?
-Mark
>
> - Brett
>
> On 26/03/2008, at 8:55 AM, Mark Diggory wrote:
>
>> Well, we've done it again,
>>
>> we have a release almost out the door and encounter an issue with
>> one of the jars that is already rsync'd into the central repo for
>> our project... All our jars are on a syncronous release cycle at
>> the moment and share the same parent version. we're cutting our
>> first major release that uses maven and its 1.5.0. We havn't
>> announced or had any users try to install it yet. Is there any
>> way to get a copy of this jar with the fix in before the artifact
>> starts being used? Is this something that if I opened a JIRA
>> request, that is could be done int he central repo, again this a
>> brand new jar that just came in yesterday.
>>
>> Our problem is that were trying to relese 1.5.0 to our community
>> and they are going to get real confused if instead we have to
>> start talking about 1.5.1 be fore it even got out the door.
>>
>> thanks for any advice,
>> Mark
>>
>> ~~~~~~~~~~~~~
>> Mark R. Diggory - DSpace Developer and Systems Manager
>> MIT Libraries, Systems and Technology Services
>> Massachusetts Institute of Technology
>>
>>
>>
>>
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
Re: replacing one jar...
Posted by Brett Porter <br...@apache.org>.
Can you announce the release with this listed as a known issue and
then do 1.5.1 to correct the problem?
As much as I want to say you could do this, the repercussions of
potentially having someone think they have the release, but instead
have this JAR, are probably longer lasting.
- Brett
On 26/03/2008, at 8:55 AM, Mark Diggory wrote:
> Well, we've done it again,
>
> we have a release almost out the door and encounter an issue with
> one of the jars that is already rsync'd into the central repo for
> our project... All our jars are on a syncronous release cycle at
> the moment and share the same parent version. we're cutting our
> first major release that uses maven and its 1.5.0. We havn't
> announced or had any users try to install it yet. Is there any way
> to get a copy of this jar with the fix in before the artifact starts
> being used? Is this something that if I opened a JIRA request, that
> is could be done int he central repo, again this a brand new jar
> that just came in yesterday.
>
> Our problem is that were trying to relese 1.5.0 to our community and
> they are going to get real confused if instead we have to start
> talking about 1.5.1 be fore it even got out the door.
>
> thanks for any advice,
> Mark
>
> ~~~~~~~~~~~~~
> Mark R. Diggory - DSpace Developer and Systems Manager
> MIT Libraries, Systems and Technology Services
> Massachusetts Institute of Technology
>
>
>
>
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/