db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Recording published Maven 2 artifacts
Date Wed, 20 Oct 2010 16:03:57 GMT
  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.


Regards,
-- 
Kristian

[1] For instance http://repo1.maven.org/maven2/org/apache/derby/derby/

[ snip ]

Mime
View raw message