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
