db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lily Wei <lily...@yahoo.com>
Subject Re: Recording published Maven 2 artifacts
Date Wed, 20 Oct 2010 16:41:22 GMT
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.
+1. It is so nice that you are working with the Maven stuff. :-)

Thanks,
Lily



      
Mime
View raw message