Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4CBF1515.8050105@oracle.com>
Date: Wed, 20 Oct 2010 09:13:09 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Recording published Maven 2 artifacts
References: <4CB41F83.2000102@oracle.com>
 <4CB45C91.9020304@oracle.com>	<wjo8wrpn8rr1.fsf@oracle.com>
 <4CB465C3.8040406@oracle.com> <wjo8sk0b8q20.fsf@oracle.com>
 <4CBD53B9.6000106@oracle.com> <4CBD9490.4000604@oracle.com>
 <4CBDA7D6.50902@oracle.com> <4CBDBC32.1020407@oracle.com>
 <4CBF12ED.5090309@oracle.com>
In-Reply-To: <4CBF12ED.5090309@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kristian Waagan wrote:
>  On 19.10.10 17:41, Rick Hillegas wrote:
>> Kristian Waagan wrote:
>>>  On 19.10.10 14:52, Rick Hillegas wrote: 
> [ snip ]
>>> Hi Rick,
>>>
>>> I agree Maven can be seen as just another distribution channel.
>>> If anyone has a suggestion for some text for the release 
>>> distributions page, that would be great!
>> Hi Kristian,
>>
>> I would keep this simple. At the end of the Distributions section of 
>> the release download page, we can just have a one line reference:
>>
>> "Maven repository for 10.6.2.1: https://blah/blah/blah"
>>>
>>>>
>>>>> Can we simply add a header "Deprecated Maven Artifacts"?
>>>> Don't see much reason to advertise the deprecated artifacts. I 
>>>> can't think of any reason that a user would need to know about any 
>>>> distribution channels other than the ones which we approve.
>>>
>>> We want to "advertise" the deprecated artifacts for the same reason 
>>> as we are advertising the deprecated Derby versions: we don't want 
>>> users to use them - either because they simply don't work or because 
>>> they contain severe bugs. The other reason is that we cannot remove 
>>> the artifacts once they have been published (do we need better 
>>> testing before deployment?).
>>> There are two different scenarios:
>>>  a) Derby version deprecated implies that the corresponding Maven 
>>> artifacts are deprecated as well.
>>>  b) Broken Maven artifacts doesn't imply that the Derby version is 
>>> deprecated.
>>>
>>> I think we already cover (a) implicitly under "Deprecated Releases". 
>>> We are discussing a home for (b).
>>> On the other side, now that the Maven scripts we use seem to have 
>>> stabilized, maybe we can just kill off this discussion right away, 
>>> in the hope that we won't produce any more broken artifacts?
>> +1 to killing off this discussion. I'm not planning to make this 
>> mistake again.
>
> Since there doesn't seem to be a consensus on whether there is a need 
> to improve the documentation of our Maven artifacts or not, I will put 
> this on hold for now.
> We can continue the discussion if we get more complaints from users at 
> some point.
>
> There is one thing I'd like to nail down though, and that is what the 
> development community wants regarding the history section in 
> maven2/README.txt. My motivation for this is that the current 
> instructions are inaccurate and may cause a little extra hassle for 
> the release manager.
>
> Based on the discussion we have had in this thread, I propose two 
> options:
>  a) update the version living on trunk, regardless of release branch
>  b) remove it - leave no traces in the code repository of Maven 
> artifact deployment, we will have to consult the Apache staging 
> repository or the central Maven repository [1] to figure out what has 
> been published
>
> Since I have been working a little with the Maven stuff, I'm 
> comfortable with option (b). This will remove one small task for the 
> release manager, so I'm giving it my +1.
+1 to reducing the complexity of our release process.

Thanks,
-Rick
>
>
> Regards,