On 19.10.10 14:52, Rick Hillegas wrote:
Kristian Waagan wrote:
On 12.10.10 16:05, Knut Anders Hatlen wrote:
Rick Hillegas<[email protected]> writes:
Knut Anders Hatlen wrote:
Rick Hillegas<[email protected]> writes:
I agree that most developers won't care about this file. It is
interesting archeology for release managers, though.
The most interesting thing in the list is that the 10.5.3.0 artifacts
are broken, and that 10.5.3.0_1 should be used instead. I think
this is
something that would interest our users too, which may suggest
that we
shouldn't hide this information in the source repository?
I agree that users would be interested in knowing that 10.5.3.0_1 is
the good distribution and 10.5.3.0 has been deprecated. Where would a
typical maven user expect to find that information? I don't use maven
much, so I don't think I could answer that question.
I have no idea about the Maven users, but I suppose a typical Derby
user
would scan the Derby website and the wiki. That said, I haven't been
able to find any information on our website/wiki on how to add Derby to
your Maven project, or any mentioning that we have Maven artifacts for
that matter, so I don't think we have any natural place to add this
information right now.
Thanks for the feedback, guys.
For now I have updated maven2/README.txt on trunk (r1024149), after
having confirmed that the artifacts have been copied from the Apache
staging repository to the central Maven repository. It has also
showed up in various other repositories/aggregator sites.
Given that we produce Maven artifacts as part of our release process,
maybe it would be enough to state that fact somewhere? We should also
mention that the artifacts usually arrive a little later than the
release itself due to the staging process.
In addition, we should have a way to tell users about
deprecated/invalid artifacts. I think the website is a better guess
than the wiki for where [Maven] users go to find this type of
information, but I don't have any proof to back that up.
The advantage of the described approach is that, except for the
one-time initial effort, the release manager doesn't have to do
anything in the normal case. Only when the community deploys broken
artifacts, action is required.
I'm thinking http://db.apache.org/derby/derby_downloads.html
Thanks for that analysis, Kristian.
Isn't the Maven repository just another distribution channel for our
release artifacts? It's a channel which works with Maven's dependency
system. Don't know if it's mirrored. I think that a better place for
this information would be on the download page for the release itself,
in the Distributions section. E.g.:
http://db.apache.org/derby/releases/release-10.6.2.1.cgi#Distributions
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!
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?
As for your other point - are you saying we don't approve the Maven
artifacts? (we are the ones producing and deploying them)
In that case, do we have to change our release process?
In my world (if I got into trouble in the first place), I would type
"maven derby 10.5.3.0 error" into a search engine and the first hit
would tell me that the problem I'm experiencing lies with the artifacts
themselves and not my own POM :) The other important piece of
information is that I can replace "10.5.3.0" with "10.5.3.0_1" and off I go.
Now, doing just that, this is the first hit on the list:
https://issues.apache.org/jira/browse/DERBY-4390
Regards,
--
Kristian
Thanks,
-Rick
---
[Deprecated Maven Artifacts]
Maven artifacts are produced for each release. It usually takes some
days before they are generally available, as they must be deployed by
the release manager and pass through a staging process.
The group id for the Derby artifacts is org.apache.derby. If you
experience problems with the Apache Derby artifacts, please let us
know at derby-user AT db DOT apache DOT org.
The following artifacts are invalid, and have been deprecated:
o 10.5.3.0, all artifacts: Invalid POMs, use version 10.5.3.0_1
instead.
---
