db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Recording published Maven 2 artifacts
Date Wed, 20 Oct 2010 16:13:09 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 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.

> Regards,

View raw message